Re: legacy PCI device behind a bridge not getting a valid IRQ on imx host controller

[Bjorn Helgaas <helgaas@kernel.org>]

On Tue, Sep 10, 2024 at 09:50:02AM -0700, Tim Harvey wrote:
> On Fri, Sep 6, 2024 at 12:58 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Sep 06, 2024 at 12:37:42PM -0700, Tim Harvey wrote:
> > > ...
> >
> > > I have the hardware in hand now as well as the out-of-tree driver
> > > that's being used. I can say there is nothing wrong here with legacy
> > > PCI interrupt mapping, if I write a skeleton driver that uses
> > > pci_resister_driver(struct pci_driver) its probe is called with an
> > > interrupt and request_irq on that interrupt succeeds just fine.
> > >
> > > The issue here is with the vendor's out-of-tree driver which instead
> > > is using pci_get_device() to scan the bus which returns a struct
> > > pci_dev * that doesn't have an irq assigned (like what is described
> > > in
> > > https://www.kernel.org/doc/html/v5.5/PCI/pci.html#how-to-find-pci-devices-manually).
> > > When using pci_get_device() when/how does pci_assign_irq() get
> > > called to assign the irq to the device?
> >
> > Hmmm.  pci_get_device() is strongly discouraged because it subverts
> > the driver model (it skips the usual driver probe/claim model so it
> > allows multiple drivers to operate the device simultaneously which can
> > obviously cause conflicts), and it doesn't play well with hotplug
> > (hotplug events automatically cause driver .probe() methods to be
> > called, but users of pci_get_device() have to roll their own way of
> > doing this).
> >
> > So I'm not aware of a documented/supported way to set up the INTx
> > interrupts in the pci_get_device() case.
> 
> Makes sense to me. Perhaps some changes to Documentation/PCI/pci.rst
> could explain this.

Yeah, that would be a good idea.

> Thanks for the help here, glad to find there is nothing broken here. I
> think there could have been some confusion by the user here because
> they were used to x86 assigning irq's without using
> pci_resister_driver() but they were also using a kernel param of
> pci=routeirq which looks like its an x86 only temporary workaround
> that may have made this work on that architecture.

I wondered about "pci=routirq", but I lost the trail and couldn't
figure out how that would lead to pci_assign_irq() or something
functionally equivalent.

Bjorn