On Wed, Sep 23, 2015 at 8:47 PM, Myron Stowe <myron.stowe@xxxxxxxxx> wrote: snip > > There is a kernel boot parameter, pci=norom, that is intended to disable the > kernel's resource assignment actions for Expansion ROMs that do not already > have BIOS assigned address ranges. Note however, if I remember correctly, > that this only works if the Expansion ROM BAR is set to "0" by the BIOS > before hand-off. In private conversations I was asked: Why do you propose asking the BIOS to assign setting Expansion ROM BARs to "0"? That is not what I'm advocating. I think it's a complete hack. Some background context - this is effectively the defacto detente that has come to be somehow with one of the major vendor's BIOS' to circumvent 'dmesg' entries corresponding to unassigned Expansion ROM BARs which draws customer attention. Unless something has changed recently, specifying "pci=norom" when booting does not cause the kernel to completely ignore Expansion ROM BARs all together as one would expect. The kernel still outputs 'dmesg's corresponding to unassigned Expansion ROM BARs and also attempts to allocate such. This is a kernel bug in my opinion. It's only if both "pci=norom" has been specified, and, the BIOS has set the Expansion ROM BARs to "0" that the kernel completely ignores Expansion ROM BARs and no 'dmesg's are output. Customers don't want to, and shouldn't have to, utilize kernel parameters. They are indispensable for kernel engineers to use for debugging and such but not for normal, every day, (i.e. customer) use. So, no, I am not advocating the current defacto detente that is in place today -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
