(This line is taken from line 284 of arch/mips/pci/pci-ar71xx.c)
It's completely software defined here although it's called "hwirq". The "hwirq" means the corresponding hardware IRQ number of the current IRQ chip. In our case here, we don't actually have a hardware IRQ chip, we just read the interrupt status register and execute the corresponding IRQ handler of pci devices. We registered an IRQ chip in pci driver but that "IRQ chip" is dummy.
I suggest adding some debug print in ar71xx_pci_irq_handler and check which bit of AR71XX_RESET_REG_PCI_INT_STATUS is triggered when receving an interrupt.
I think I can't help further here due to lack of a router.
That's too hard for me to debug.
Do you have devmem installed in your firmware? After reading some code I guess the pci interrupt are incorrectly masked. If you are free you can try to dump RST_PCI_INTERRUPT_MASK(0x1806001c). I guess the correct value of the last three bit should be 011 (0x3) and the value on ath79 will be 110 (0x6).
I'm quite confused now. Similar problems exist on both pci-ar71xx and pci-ar724x but how could pci-ar724x works with a broken interrupt-map and a broken mask/unmask function?
At least it shows that the mask is incorrect(although the value is unexpected). I'll do some debug on my qca9558 router later
At least I know why the broken pci-ar724x works now...
Somehow the incorrect interrupt-controller property defined there caused all the devices bind to the first IRQ on the registered dummy IRQ chip, and this is correct for those pcie controller since there will be only one possible device on each pcie controller.
The mask/unmask function called irq_linear_revmap(apc->domain, d->irq) with incorrect arguments, and irq_linear_revmap will return 0 when arguments are invalid, and 0 is the correct bit to mask/unmask the interrupt controller.
@Pilot6 How did you get devmem to work?
I am trying to debug a GPIO register but even with CONFIG_KERNEL_DEVMEM and CONFIG_KERNEL_DEVKMEM enabled in kernel config devmem complains about /dev/mem not being available
@981213 Do we really need the interrupt-controller subnode?
The problem was not with mapping. If we set different interrupts in ath9k nodes, it should work the same way now.
It is more convenient to configure mappings in case of different devices though.