On Thursday, February 24, 2011 01:09:25 am Jan Beulich wrote: > >>> On 23.02.11 at 22:00, Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: > > There are good reasons why a BIOS might hide a PCI device. For > > example, if SMM code uses a PCI device, the BIOS must prevent the > > OS from moving it. One way would be to hide the device from PCI > > enumeration and then expose it via the ACPI namespace, where the > > _CRS/_PRS/_SRS methods allow the BIOS to control the configuration. > > > > I know there's some tension here -- things like EDAC want to use > > devices we "know" are there, while the BIOS might need to hide things > > to keep our mitts off them. I'm not sure there's a reliable way to > > tell when it's safe for us to go around the BIOS intent. > > I had tried for several months to get a statement from Intel on this > behavior, without any success. What sort of statement were you looking for? If *I* were an OEM, I would say "the OS can use anything it discovers via the architected ACPI and PCI discovery mechanisms, and should leave everything else alone." I don't think any OEM is going to sign up to support things the OS finds by poking around blindly. > > Nobody wants to give up EDAC functionality, but in the long term, it > > might be better to say, "Well, your OEM doesn't want to support > > functionality X even though the hardware is there, so consider that > > when you're choosing your next system." Or maybe we taint the kernel > > when we circumvent the BIOS like this. At a minimum, I think we should > > log a note in dmesg. > > That's already the case: "PCI: Discovered peer bus ..." Well, ... OK, but that particular message is completely neutral and gives no indication that we're finding devices the OEM didn't intend to support. I'd rather see something that specific to the device that suggested "hey, we found this device the BIOS didn't report; we're going to use it, but be aware that it might not work correctly." Bjorn -- 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
