>>> On 24.02.11 at 17:05, Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: > 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. The way I discovered this was that Xen actually enumerates those devices (doing an old-style brute force scan), while Linux deosn't. So the clarification I was (am) after is whether those devices are hidden by mistake or on purpose, and whether the workaround ($subject patch) would be suitable. Jan -- 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
