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? Thierry
Attachment:
pgpDmvXuSpl8H.pgp
Description: PGP signature
