On Fri, Nov 3, 2017 at 12:52 PM, Ryder Lee <ryder.lee@xxxxxxxxxxxx> wrote: > On Fri, 2017-11-03 at 10:40 +0100, Arnd Bergmann wrote: >> On Fri, Nov 3, 2017 at 2:37 AM, Ryder Lee <ryder.lee@xxxxxxxxxxxx> wrote: >> This should have the exact same effect as what you have in your tree, >> but if that works, >> we can merge that version and try to figure out why the kernel thinks >> they are different. > > I've tried this approach by using the 4-ports network card and got the > result: > pcieport 0000:00:01.0: assign IRQ: got 220 > pcieport 0000:00:01.0: assigning IRQ 220 > pcieport 0000:00:01.0: enabling device (0140 -> 0142) > pcieport 0000:00:01.0: enabling bus mastering > pcieport 0000:00:01.0: Signaling PME with IRQ 220 > .... > igb 0000:01:00.0: assign IRQ: got 221 > igb 0000:01:00.0: assigning IRQ 221 > igb 0000:01:00.1: assign IRQ: got 221 > igb 0000:01:00.1: assigning IRQ 221 > igb 0000:01:00.2: assign IRQ: got 221 > igb 0000:01:00.2: assigning IRQ 221 > igb 0000:01:00.3: assign IRQ: got 221 > igb 0000:01:00.3: assigning IRQ 221 > > I think slot 1 should share its IRQ (220) with every device in the > hierarchy below this root port. Agreed, that is what I expected, too. I've looked at the of_pci_irq.c in more detail but couldn't come up with what happened. Can you try running with this patch or something like that to figure out where it takes the wrong turn? https://pastebin.com/MrMzwcmw Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
