On Wed, 23 Feb 2011 14:00:53 -0700 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. > > 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. But maybe using MCFG's bus numbers *is* the canonical way of getting the max bus... I don't know what Windows does here, but I can imagine that it exposes all these devices to various drivers. Perhaps they're hidden so that earlier versions of Windows won't "yellow bang" the unknown devices, while newer versions use MCFG. Does anyone have an affected machine with Windows 7 or something so we can verify? Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- 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
