On Tue, Sep 18, 2012 at 12:33 AM, Thierry Reding <thierry.reding@xxxxxxxxxxxxxxxxx> wrote: > On Sat, Sep 08, 2012 at 11:51:00AM -0600, Bjorn Helgaas wrote: >> On Fri, Sep 7, 2012 at 6:04 PM, Russell King - ARM Linux >> <linux@xxxxxxxxxxxxxxxx> 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? >> >> It seems that there are some bugs in the PCI layer, no doubt >> introduced after all your hard work. We'll do our best to fix them. >> >> The particular issue of pci_fixup_irqs() has been on my list for a >> while, and we talked about it at the recent PCI mini-summit. It's >> clearly broken that we do this with for_each_pci_dev() once at >> boot-time because that does nothing for hot-added devices. It's also >> broken that it is called after device_add() because the core shouldn't >> touch the device after it's available to drivers. >> >> This should get fixed reasonably soon, probably not in v3.6, but >> hopefully in v3.7. It's not completely trivial because many arches >> have the same problem, and we need to fix all of them. > > Has there been any progress on this? I've read the PCI mini summit notes > that you posted a while ago but it doesn't mention the pci_fixup_irqs() > issue. Was there some decision as to how this should be solved? If I > understand correctly this should solve the issue that Stephen has been > seeing with bogus interrupt assignments, so we'll need this to fix PCIe > on Tegra. Is there anything I can do to help move this forward? I didn't mention pci_fixup_irqs() by name in the notes, but that's part of what I meant by "device setup being done by initcalls" as a hot-plug issue. I know Myron Stowe expressed interest in working on that, but I don't think he's had a chance to do anything yet (at least, I haven't seen anything yet). I don't have time to fix it myself, so moving it forward is just a matter of somebody doing the work and posting the patches. I think that code just needs to be moved to some pcibios hook (possibly a new one) that's called in the device_add path. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html