On Tue, Sep 10, 2024 at 4:04 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > 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@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. > > > > 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. > Hi Bjorn and Frank, While switching to pci_resister_driver() resolves the request_irq issue I find that legacy IRQ's fire on the imx8mm/imx8mp only when the device is not behind a bridge: Again this specific device is a DDK BU-69092S1 which has a TI XIO2001 PCIe-to-PCI bridge with a PCI device behind it. Here is an example of a GW72xx (which has a PI7C9X2G404E 4-port PCIe switch) with an imx8mm: root@noble-venice:~# uname -r 6.6.8-gc6ef8b5e47a0 root@noble-venice:~# lspci -n 00:00.0 0604: 16c3:abcd (rev 01) 01:00.0 0604: 12d8:b404 (rev 01) 02:01.0 0604: 12d8:b404 (rev 01) 02:02.0 0604: 12d8:b404 (rev 01) 02:03.0 0604: 12d8:b404 (rev 01) 04:00.0 0604: 104c:8240 05:00.0 0780: 4ddc:1a00 (rev 10) 05:01.0 0780: 4ddc:1a00 (rev 10) 06:00.0 0200: 1055:7430 (rev 11) root@noble-venice:~# lspci -s 05:00 -vvv | grep Interrupt Interrupt: pin A routed to IRQ 206 root@noble-venice:~# grep 206 /proc/interrupts 206: 0 0 0 0 GICv3 157 Level PCIe PME ^^^ makes sense... driver has probed and requested the IRQ but nothing has made it fire yet root@noble-venice:~# ./tester Testing.....Registers Passed test. Testing.....Ram Passed 1234 test. Testing.....Ram Passed aaaa test. Testing.....Ram Passed aa55 test. Testing.....Ram Passed 55aa test. Testing.....Ram Passed 5555 test. Testing.....Ram Passed ffff test. Testing.....Ram Passed 1111 test. Testing.....Ram Passed 8888 test. Testing.....Ram Passed 0000 test. Testing.....Interrupt Test Failure, NO IRQ!!! Testing.....Protocol Test RTL Function Failure-> Function not supported. Testing.....Vector Test RTL Function Failure-> Function not supported. EXIT: tester ^^^ this app causes the device to fire an IRQ and verifies its been caught; fails due to no irq firing root@noble-venice:~# grep 206 /proc/interrupts 206: 0 0 0 0 GICv3 157 Level PCIe PME ^^^ 0 interrupts Here is an example of the same device on a GW71xx (which has no switch) with an imx8mm: root@noble-venice:~# uname -r 6.6.8-gc6ef8b5e47a0 root@noble-venice:~# lspci -n 00:00.0 0604: 16c3:abcd (rev 01) 01:00.0 0604: 104c:8240 02:00.0 0780: 4ddc:1a00 (rev 10) 02:01.0 0780: 4ddc:1a00 (rev 10) root@noble-venice:~# lspci -s 02:00 -vvv | grep Interrupt Interrupt: pin A routed to IRQ 204 root@noble-venice:~# grep 204 /proc/interrupts 204: 0 0 0 0 GICv3 157 Level PCIe PME root@noble-venice:~# ./tester Testing.....Registers Passed test. Testing.....Ram Passed 1234 test. Testing.....Ram Passed aaaa test. Testing.....Ram Passed aa55 test. Testing.....Ram Passed 55aa test. Testing.....Ram Passed 5555 test. Testing.....Ram Passed ffff test. Testing.....Ram Passed 1111 test. Testing.....Ram Passed 8888 test. Testing.....Ram Passed 0000 test. Testing.....Interrupt Occurred, Passed test. Testing.....Protocol Test RTL Function Failure-> Function not supported. Testing.....Vector Test RTL Function Failure-> Function not supported. EXIT: tester root@noble-venice:~# grep 204 /proc/interrupts 204: 1 0 0 0 GICv3 157 Level PCIe PME I believe this issue is likely the same thing I enquired about over a year ago [1] showing with an ath9k device which uses legacy IRQ's which I've also never resolved. Any ideas here? Best Regards, Tim
