On Fri, Sep 6, 2024 at 12:58 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> 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. > Hi Bjorn, Makes sense to me. Perhaps some changes to Documentation/PCI/pci.rst could explain this. 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. Best Regards, Tim
