[PATCH v1 00/12] PCI: Rework shadow ROM handling
On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
> The purpose of this series is to:
> ...
> - Move arch-specific shadow ROM location knowledge, e.g.,
> 0xC-0xD, from PCI core to arch code.
> ...
> Bjorn Helgaas (12):
> PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED
> PCI: Don't assign or reassign immutable resources
> PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copy
> PCI: Set ROM shadow location in arch code, not in PCI core
I propose to add the patch below at this point in the series.
> PCI: Clean up pci_map_rom() whitespace
> ia64/PCI: Use temporary struct resource * to avoid repetition
> ia64/PCI: Use ioremap() instead of open-coded equivalent
> ia64/PCI: Keep CPU physical (not virtual) addresses in shadow ROM
> resource
> MIPS: Loongson 3: Use temporary struct resource * to avoid repetition
> MIPS: Loongson 3: Keep CPU physical (not virtual) addresses in shadow
> ROM resource
> PCI: Remove unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY
> PCI: Simplify sysfs ROM cleanup
commit ac0c302a919ba7b68dbf274babdc08c83df6f532
Author: Bjorn Helgaas
Date: Sat Mar 12 05:48:08 2016 -0600
PCI: Remove arch-specific IORESOURCE_ROM_SHADOW size from sysfs
When pci_create_sysfs_dev_files() created the "rom" sysfs file, it set the
sysfs file size to the actual size of a ROM BAR, or if there was no ROM BAR
but the platform provided a shadow copy in RAM, to 0x2. 0x2 is an
arch-specific length that should not be baked into the PCI core.
Every place that sets IORESOURCE_ROM_SHADOW also sets the size of the
PCI_ROM_RESOURCE, so use the resource length always.
Signed-off-by: Bjorn Helgaas
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 95d9e7b..51d4dad 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1356,7 +1356,7 @@ error:
int __must_check pci_create_sysfs_dev_files(struct pci_dev *pdev)
{
int retval;
- int rom_size = 0;
+ int rom_size;
struct bin_attribute *attr;
if (!sysfs_initialized)
@@ -1373,12 +1373,8 @@ int __must_check pci_create_sysfs_dev_files(struct
pci_dev *pdev)
if (retval)
goto err_config_file;
- if (pci_resource_len(pdev, PCI_ROM_RESOURCE))
- rom_size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
- else if (pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW)
- rom_size = 0x2;
-
/* If the device has a ROM, try to expose it in sysfs. */
+ rom_size = pci_resource_len(pdev, PCI_ROM_RESOURCE);
if (rom_size) {
attr = kzalloc(sizeof(*attr), GFP_ATOMIC);
if (!attr) {
[PATCH v1 00/12] PCI: Rework shadow ROM handling
On Fri, Mar 11, 2016 at 8:09 PM, Linus Torvalds wrote: > On Fri, Mar 11, 2016 at 4:49 PM, Andy Lutomirski > wrote: >> >> FWIW, if I disable all the checks in pci_get_rom_size, I learn that my >> video ROM consists entirely of 0xff bytes. Maybe there just isn't a >> ROM shadow on my laptop. > > I think most laptops end up having the graphics ROM be part of the > regular system flash, and there is no actual rom associated with the > PCI device that is the GPU itself. > > The actual GPU ROM tends to be associated with plug-in cards, not > soldered-down chips in a laptop where they don't want extra flash > chips. Right; on (at least AMD) mobile dGPUs and systems with APUs, the vbios "rom" is part of the sbios image and is set up by the sbios when it runs. The driver either gets it from the legacy vga location or some platform specific method such as ACPI. Alex
[PATCH v1 00/12] PCI: Rework shadow ROM handling
On Fri, Mar 11, 2016 at 01:16:09PM -0800, Andy Lutomirski wrote:
> On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote:
> > On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
> >> The purpose of this series is to:
> >>
> >> - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment"
> >> messages reported by Linus [1], Andy [2], and others.
> >>
> >> - Move arch-specific shadow ROM location knowledge, e.g.,
> >> 0xC-0xD, from PCI core to arch code.
> >>
> >> - Fix the ia64 and MIPS Loongson 3 oddity of keeping virtual
> >> addresses in shadow ROM struct resource (resources should always
> >> contain *physical* addresses).
> >>
> >> - Remove now-unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY
> >> flags.
> >>
> >> This series is based on v4.5-rc1, and it's available on my
> >> pci/resource git branch (along with a couple tiny unrelated patches)
> >> at [3].
> >>
> >> Bjorn
> >>
> >>
> >> [1]
> >> http://lkml.kernel.org/r/CA+55aFyVMfTBB0oz_yx8+eQOEJnzGtCsYSj9QuhEpdZ9BHdq5A
> >> at mail.gmail.com
> >> [2]
> >> http://lkml.kernel.org/r/CALCETrV+RwNPzxyL8UVNsrAGu-6cCzD_Cc9PFJT2NCTJPLZZiw
> >> at mail.gmail.com
> >> [3]
> >> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/resource
> >>
> >>
> >> ---
> >>
> >> Bjorn Helgaas (12):
> >> PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED
> >> PCI: Don't assign or reassign immutable resources
> >> PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copy
> >> PCI: Set ROM shadow location in arch code, not in PCI core
> >> PCI: Clean up pci_map_rom() whitespace
> >> ia64/PCI: Use temporary struct resource * to avoid repetition
> >> ia64/PCI: Use ioremap() instead of open-coded equivalent
> >> ia64/PCI: Keep CPU physical (not virtual) addresses in shadow ROM
> >> resource
> >> MIPS: Loongson 3: Use temporary struct resource * to avoid repetition
> >> MIPS: Loongson 3: Keep CPU physical (not virtual) addresses in
> >> shadow ROM resource
> >> PCI: Remove unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY
> >> PCI: Simplify sysfs ROM cleanup
> >>
> >>
> >> arch/ia64/pci/fixup.c | 21 +++--
> >> arch/ia64/sn/kernel/io_acpi_init.c | 22 ++
> >> arch/ia64/sn/kernel/io_init.c | 51 --
> >> arch/mips/pci/fixup-loongson3.c| 19 +---
> >> arch/x86/pci/fixup.c | 21 +++--
> >> drivers/pci/pci-sysfs.c| 13 +-
> >> drivers/pci/remove.c |1
> >> drivers/pci/rom.c | 83
> >> +++-
> >> drivers/pci/setup-res.c|6 +++
> >> include/linux/ioport.h |4 --
> >> 10 files changed, 111 insertions(+), 130 deletions(-)
> >
> > I applied this series to pci/resource for v4.6.
>
> This gets rid of all the warnings for me until I try to read my i915
> device's rom using sysfs. Then I get:
>
> i915 :00:02.0: Invalid PCI ROM header signature: expecting 0xaa55,
> got 0x
>
> So I suspect that something is still subtly wrong -- I'd imagine that
> this should either work or the intialization code should detect that
> there is no usable ROM and not expose it.
>
> (To be clear, there's no regression here.)
Hmmm. Thanks for testing this. As you say, I think this is the way
it's always been, but it does seem non-intuitive.
That "Invalid PCI ROM header signature" warning comes from
pci_get_rom_size(). We don't call that at enumeration-time; we only
call it later when somebody tries to read the ROM via sysfs:
pci_bus_add_device
pci_fixup_device(pci_fixup_final)
pci_fixup_video # final fixup
res->flags = MEM | SHADOW | PCI_FIXED
pci_create_sysfs_dev_files
if (SHADOW)
rom_size = 0x2# oops, I should have fixed this too
if (rom_size)
attr->read = pci_read_rom
sysfs_create_bin_file # sysfs "rom" file
pci_read_rom# sysfs "rom" read function
pci_map_rom
ioremap
pci_get_rom_size
dev_err("Invalid PCI ROM header signature")
memcpy_fromio
pci_unmap_rom
I think this is the same for regular ROMs on the device as it is for
the magic VGA shadow ROM. In both cases, we create the sysfs "rom"
file regardless of what the ROM contains.
I guess we could try to read the ROM at enumeration time and look for
a valid signature. I've considered doing that anyway so we could
cache the ROM contents and avoid permanently allocating MMIO space for
it, since many BIOSes don't allocate space, and Linux isn't really smart
enough to do a good job of it itself.
I don't know why the PCI core cares about the ROM signature anyway,
since it doesn't use the content. Maybe we should get rid of
pci_get_rom_size() and allow you to read whatever is there, like
we do for other BARs. I su
[PATCH v1 00/12] PCI: Rework shadow ROM handling
On Fri, Mar 11, 2016 at 4:49 PM, Andy Lutomirski wrote: > > FWIW, if I disable all the checks in pci_get_rom_size, I learn that my > video ROM consists entirely of 0xff bytes. Maybe there just isn't a > ROM shadow on my laptop. I think most laptops end up having the graphics ROM be part of the regular system flash, and there is no actual rom associated with the PCI device that is the GPU itself. The actual GPU ROM tends to be associated with plug-in cards, not soldered-down chips in a laptop where they don't want extra flash chips. Linus
[PATCH v1 00/12] PCI: Rework shadow ROM handling
On Fri, Mar 11, 2016 at 3:29 PM, Bjorn Helgaas wrote:
> On Fri, Mar 11, 2016 at 01:16:09PM -0800, Andy Lutomirski wrote:
>> On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote:
>> > On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
>> >> The purpose of this series is to:
>> >>
>> >> - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment"
>> >> messages reported by Linus [1], Andy [2], and others.
>> >>
>> >> - Move arch-specific shadow ROM location knowledge, e.g.,
>> >> 0xC-0xD, from PCI core to arch code.
>> >>
>> >> - Fix the ia64 and MIPS Loongson 3 oddity of keeping virtual
>> >> addresses in shadow ROM struct resource (resources should always
>> >> contain *physical* addresses).
>> >>
>> >> - Remove now-unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY
>> >> flags.
>> >>
>> >> This series is based on v4.5-rc1, and it's available on my
>> >> pci/resource git branch (along with a couple tiny unrelated patches)
>> >> at [3].
>> >>
>> >> Bjorn
>> >>
>> >>
>> >> [1]
>> >> http://lkml.kernel.org/r/CA+55aFyVMfTBB0oz_yx8+eQOEJnzGtCsYSj9QuhEpdZ9BHdq5A
>> >> at mail.gmail.com
>> >> [2]
>> >> http://lkml.kernel.org/r/CALCETrV+RwNPzxyL8UVNsrAGu-6cCzD_Cc9PFJT2NCTJPLZZiw
>> >> at mail.gmail.com
>> >> [3]
>> >> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/resource
>> >>
>> >>
>> >> ---
>> >>
>> >> Bjorn Helgaas (12):
>> >> PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED
>> >> PCI: Don't assign or reassign immutable resources
>> >> PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copy
>> >> PCI: Set ROM shadow location in arch code, not in PCI core
>> >> PCI: Clean up pci_map_rom() whitespace
>> >> ia64/PCI: Use temporary struct resource * to avoid repetition
>> >> ia64/PCI: Use ioremap() instead of open-coded equivalent
>> >> ia64/PCI: Keep CPU physical (not virtual) addresses in shadow ROM
>> >> resource
>> >> MIPS: Loongson 3: Use temporary struct resource * to avoid
>> >> repetition
>> >> MIPS: Loongson 3: Keep CPU physical (not virtual) addresses in
>> >> shadow ROM resource
>> >> PCI: Remove unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY
>> >> PCI: Simplify sysfs ROM cleanup
>> >>
>> >>
>> >> arch/ia64/pci/fixup.c | 21 +++--
>> >> arch/ia64/sn/kernel/io_acpi_init.c | 22 ++
>> >> arch/ia64/sn/kernel/io_init.c | 51 --
>> >> arch/mips/pci/fixup-loongson3.c| 19 +---
>> >> arch/x86/pci/fixup.c | 21 +++--
>> >> drivers/pci/pci-sysfs.c| 13 +-
>> >> drivers/pci/remove.c |1
>> >> drivers/pci/rom.c | 83
>> >> +++-
>> >> drivers/pci/setup-res.c|6 +++
>> >> include/linux/ioport.h |4 --
>> >> 10 files changed, 111 insertions(+), 130 deletions(-)
>> >
>> > I applied this series to pci/resource for v4.6.
>>
>> This gets rid of all the warnings for me until I try to read my i915
>> device's rom using sysfs. Then I get:
>>
>> i915 :00:02.0: Invalid PCI ROM header signature: expecting 0xaa55,
>> got 0x
>>
>> So I suspect that something is still subtly wrong -- I'd imagine that
>> this should either work or the intialization code should detect that
>> there is no usable ROM and not expose it.
>>
>> (To be clear, there's no regression here.)
>
> Hmmm. Thanks for testing this. As you say, I think this is the way
> it's always been, but it does seem non-intuitive.
>
> That "Invalid PCI ROM header signature" warning comes from
> pci_get_rom_size(). We don't call that at enumeration-time; we only
> call it later when somebody tries to read the ROM via sysfs:
>
> pci_bus_add_device
> pci_fixup_device(pci_fixup_final)
> pci_fixup_video # final fixup
> res->flags = MEM | SHADOW | PCI_FIXED
> pci_create_sysfs_dev_files
> if (SHADOW)
> rom_size = 0x2# oops, I should have fixed this too
> if (rom_size)
> attr->read = pci_read_rom
> sysfs_create_bin_file # sysfs "rom" file
>
> pci_read_rom# sysfs "rom" read function
> pci_map_rom
> ioremap
> pci_get_rom_size
> dev_err("Invalid PCI ROM header signature")
> memcpy_fromio
> pci_unmap_rom
>
> I think this is the same for regular ROMs on the device as it is for
> the magic VGA shadow ROM. In both cases, we create the sysfs "rom"
> file regardless of what the ROM contains.
>
> I guess we could try to read the ROM at enumeration time and look for
> a valid signature. I've considered doing that anyway so we could
> cache the ROM contents and avoid permanently allocating MMIO space for
> it, since many BIOSes don't allocate space, and Linux isn't really smart
> enough to do a good job of it itself.
>
> I don't know w
[PATCH v1 00/12] PCI: Rework shadow ROM handling
On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote: > On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote: >> The purpose of this series is to: >> >> - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment" >> messages reported by Linus [1], Andy [2], and others. >> >> - Move arch-specific shadow ROM location knowledge, e.g., >> 0xC-0xD, from PCI core to arch code. >> >> - Fix the ia64 and MIPS Loongson 3 oddity of keeping virtual >> addresses in shadow ROM struct resource (resources should always >> contain *physical* addresses). >> >> - Remove now-unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY >> flags. >> >> This series is based on v4.5-rc1, and it's available on my >> pci/resource git branch (along with a couple tiny unrelated patches) >> at [3]. >> >> Bjorn >> >> >> [1] >> http://lkml.kernel.org/r/CA+55aFyVMfTBB0oz_yx8+eQOEJnzGtCsYSj9QuhEpdZ9BHdq5A >> at mail.gmail.com >> [2] >> http://lkml.kernel.org/r/CALCETrV+RwNPzxyL8UVNsrAGu-6cCzD_Cc9PFJT2NCTJPLZZiw >> at mail.gmail.com >> [3] >> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/resource >> >> >> --- >> >> Bjorn Helgaas (12): >> PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED >> PCI: Don't assign or reassign immutable resources >> PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copy >> PCI: Set ROM shadow location in arch code, not in PCI core >> PCI: Clean up pci_map_rom() whitespace >> ia64/PCI: Use temporary struct resource * to avoid repetition >> ia64/PCI: Use ioremap() instead of open-coded equivalent >> ia64/PCI: Keep CPU physical (not virtual) addresses in shadow ROM >> resource >> MIPS: Loongson 3: Use temporary struct resource * to avoid repetition >> MIPS: Loongson 3: Keep CPU physical (not virtual) addresses in shadow >> ROM resource >> PCI: Remove unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY >> PCI: Simplify sysfs ROM cleanup >> >> >> arch/ia64/pci/fixup.c | 21 +++-- >> arch/ia64/sn/kernel/io_acpi_init.c | 22 ++ >> arch/ia64/sn/kernel/io_init.c | 51 -- >> arch/mips/pci/fixup-loongson3.c| 19 +--- >> arch/x86/pci/fixup.c | 21 +++-- >> drivers/pci/pci-sysfs.c| 13 +- >> drivers/pci/remove.c |1 >> drivers/pci/rom.c | 83 >> +++- >> drivers/pci/setup-res.c|6 +++ >> include/linux/ioport.h |4 -- >> 10 files changed, 111 insertions(+), 130 deletions(-) > > I applied this series to pci/resource for v4.6. This gets rid of all the warnings for me until I try to read my i915 device's rom using sysfs. Then I get: i915 :00:02.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x So I suspect that something is still subtly wrong -- I'd imagine that this should either work or the intialization code should detect that there is no usable ROM and not expose it. (To be clear, there's no regression here.)
[PATCH v1 00/12] PCI: Rework shadow ROM handling
On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote: > The purpose of this series is to: > > - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment" > messages reported by Linus [1], Andy [2], and others. > > - Move arch-specific shadow ROM location knowledge, e.g., > 0xC-0xD, from PCI core to arch code. > > - Fix the ia64 and MIPS Loongson 3 oddity of keeping virtual > addresses in shadow ROM struct resource (resources should always > contain *physical* addresses). > > - Remove now-unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY > flags. > > This series is based on v4.5-rc1, and it's available on my > pci/resource git branch (along with a couple tiny unrelated patches) > at [3]. > > Bjorn > > > [1] > http://lkml.kernel.org/r/CA+55aFyVMfTBB0oz_yx8+eQOEJnzGtCsYSj9QuhEpdZ9BHdq5A > at mail.gmail.com > [2] > http://lkml.kernel.org/r/CALCETrV+RwNPzxyL8UVNsrAGu-6cCzD_Cc9PFJT2NCTJPLZZiw > at mail.gmail.com > [3] > https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/resource > > > --- > > Bjorn Helgaas (12): > PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED > PCI: Don't assign or reassign immutable resources > PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copy > PCI: Set ROM shadow location in arch code, not in PCI core > PCI: Clean up pci_map_rom() whitespace > ia64/PCI: Use temporary struct resource * to avoid repetition > ia64/PCI: Use ioremap() instead of open-coded equivalent > ia64/PCI: Keep CPU physical (not virtual) addresses in shadow ROM > resource > MIPS: Loongson 3: Use temporary struct resource * to avoid repetition > MIPS: Loongson 3: Keep CPU physical (not virtual) addresses in shadow > ROM resource > PCI: Remove unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY > PCI: Simplify sysfs ROM cleanup > > > arch/ia64/pci/fixup.c | 21 +++-- > arch/ia64/sn/kernel/io_acpi_init.c | 22 ++ > arch/ia64/sn/kernel/io_init.c | 51 -- > arch/mips/pci/fixup-loongson3.c| 19 +--- > arch/x86/pci/fixup.c | 21 +++-- > drivers/pci/pci-sysfs.c| 13 +- > drivers/pci/remove.c |1 > drivers/pci/rom.c | 83 > +++- > drivers/pci/setup-res.c|6 +++ > include/linux/ioport.h |4 -- > 10 files changed, 111 insertions(+), 130 deletions(-) I applied this series to pci/resource for v4.6.
[PATCH v1 00/12] PCI: Rework shadow ROM handling
The purpose of this series is to: - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment" messages reported by Linus [1], Andy [2], and others. - Move arch-specific shadow ROM location knowledge, e.g., 0xC-0xD, from PCI core to arch code. - Fix the ia64 and MIPS Loongson 3 oddity of keeping virtual addresses in shadow ROM struct resource (resources should always contain *physical* addresses). - Remove now-unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY flags. This series is based on v4.5-rc1, and it's available on my pci/resource git branch (along with a couple tiny unrelated patches) at [3]. Bjorn [1] http://lkml.kernel.org/r/CA+55aFyVMfTBB0oz_yx8+eQOEJnzGtCsYSj9QuhEpdZ9BHdq5A at mail.gmail.com [2] http://lkml.kernel.org/r/CALCETrV+RwNPzxyL8UVNsrAGu-6cCzD_Cc9PFJT2NCTJPLZZiw at mail.gmail.com [3] https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/resource --- Bjorn Helgaas (12): PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED PCI: Don't assign or reassign immutable resources PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copy PCI: Set ROM shadow location in arch code, not in PCI core PCI: Clean up pci_map_rom() whitespace ia64/PCI: Use temporary struct resource * to avoid repetition ia64/PCI: Use ioremap() instead of open-coded equivalent ia64/PCI: Keep CPU physical (not virtual) addresses in shadow ROM resource MIPS: Loongson 3: Use temporary struct resource * to avoid repetition MIPS: Loongson 3: Keep CPU physical (not virtual) addresses in shadow ROM resource PCI: Remove unused IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY PCI: Simplify sysfs ROM cleanup arch/ia64/pci/fixup.c | 21 +++-- arch/ia64/sn/kernel/io_acpi_init.c | 22 ++ arch/ia64/sn/kernel/io_init.c | 51 -- arch/mips/pci/fixup-loongson3.c| 19 +--- arch/x86/pci/fixup.c | 21 +++-- drivers/pci/pci-sysfs.c| 13 +- drivers/pci/remove.c |1 drivers/pci/rom.c | 83 +++- drivers/pci/setup-res.c|6 +++ include/linux/ioport.h |4 -- 10 files changed, 111 insertions(+), 130 deletions(-)
[PATCH v1 00/12] PCI: Rework shadow ROM handling
On Thu, Mar 3, 2016 at 8:53 AM, Bjorn Helgaas wrote: > The purpose of this series is to: > [ .. ] The patches look ok to me and seem to make sense. Of course, let's see what they break. Hopefully nothing, but any time the PCI resource code changes I get a bit worried. PTSD, I guess. Linus
