* Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>: > > Here's the output from my machine, including ACPI paths (summary of not > found stuff at the top): > > ... > [ 0.177188] + Adding \_SB_.PCI0.AGP_ > [ 0.177294] pci_bus 0000:00: I'm a little pci_bus, short and stout... > [ 0.177407] Searching for 0000:00:01.0...not found > ... > [ 0.179259] + Adding \_SB_.PCI0.EXP2 > [ 0.179364] pci_bus 0000:00: I'm a little pci_bus, short and stout... > [ 0.179477] Searching for 0000:00:1c.2...not found > ... > [ 0.180128] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT] > [ 0.180200] Starting root bridge search from \_SB_.PCI0.EXP3.EXUP > [ 0.180310] + Adding \_SB_.PCI0.EXP3.EXUP > [ 0.180418] + Adding \_SB_.PCI0.EXP3 > [ 0.180523] pci_bus 0000:00: I'm a little pci_bus, short and stout... > [ 0.180636] Searching for 0000:00:1c.3...found > [ 0.180787] Searching for 0000:05:00.0...not found > ... > > So looks like one is an express slot, another is the AGP this machine > lacks, and then there's this 05:00.0; not sure what that is. > > At any rate, it does appear we have to take care not to assume > *everything* in the ACPI tree has an associated PCI dev, since > namespaces could be shared accross different platforms with just enable > or present bits to mask them out from the initial PCI scan. Yup, as per our irc discussion, I'm now a lot more confident that this was the root cause. Troy's original patch is correct, just needs an explanation of _why_. :) I'll send a patch updating acpi_get_pci_dev() with a comment that explains the "why". Thanks everyone. /ac -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
