On 09/07/2012 06:04 PM, Russell King - ARM Linux wrote: > On Fri, Sep 07, 2012 at 05:34:35PM -0600, Stephen Warren wrote: >> I guess it's a pretty basic premise of the current PCI code that all the >> PCI scanning happens well before any device drivers are registered, >> which in turn means that device_add() doesn't trigger the device's >> probe() until much later, after all the fixups and resource assignments >> are done? > > Are you saying that the PCI layer is again screwed up after all my > hard work several years ago to ensure that PCI devices are properly > setup _before_ they're made available to the PCI drivers then? That > was around the time I was looking at Cardbus stuff, ensuring that that > worked with the same guarantees. > > Not amused. > > What is wrong with the "probe devices, apply fixups, setup resources, > apply more fixups, publish" process that it's had to be yet again > broken? I must admit, I'm having a hard time finding when the code worked like that; ARM's bios32.c:pcibios_init_hw() seems to have always called pci_scan_root_bus(), or ops function hw->scan(), which at least in the 1 PCIe controller driver I looked at, in turn always called either pci_scan_root_bus() or another similar function that I believe always called pci_bus_add_devices(), which is before pci_common_init() could assign the resources. Maybe I'm just looking at the wrong PCIe controller driver, or not looking back far enough in git history (or pre-git)? If you could point out when it was working as you describe (which sounds reasonable), I'd be interested in tracing the history from there to see when/why it changed. -- 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
