> Cc'ing Ben for PPC. Ben, should PPC use pci_scan_device when probing > its root busses? Sounds like it just uses pci_device_add for each one > it finds instead? > > If you don't actually need scanning (though what about hotplug?) we can > move the call to device_add instead... Ok so I looked at the code and the problem goes way beyond root busses. Basically, powerpc can use the code in arch/powerpc/kernel/pci_of_scan.c to "generate" the pci_dev without using config space probing or at least using as little of it as possible, using the firmware device-tree information instead. This is also probably going to be moved to a more generic place and extended to be used optionally by other architectures. I think sparc does something similar in fact in arch/sparc/kernel/pci.c (of_create_pci_dev()) though it would be logical to have sparc and powerpc share the same implementation here in the long run and I believe Grant Likely is working on it. That means that potentially, pci_dev will be created on those archs for which pci_setup_device() is never called. Thus we need to be very careful when adding initializations there that at least we (myself and davem) are notified of that so we can mirror them in our code, or even better, if people doing so put them there too... So as far as I can tell, we are missing that set_pcie_port_type(), so we need to add it to sparc and powerpc (and so make the function non-static in drivers/pci/probe.c). We are also missing the manipulation of dev->slot in fact, so that will need to be fixed too. set_pcie_hotplug_bridge() might be something we want to add too, it's not totally clear yet due to possible issues with our firmwares. pci_fixup_device(pci_fixup_early,...) as well in fact. I'll try do make ppc catch up with some of that see how it goes. Cheers, Ben. -- 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
