Re: [PATCH v3] gpio: mt7621: fix interrupt banks mapping on gpio chips

[Sergio Paracuellos]

On Tue, Jun 9, 2026 at 1:36 PM Bartosz Golaszewski <brgl@xxxxxxxxxx> wrote:
>
> On Tue, 9 Jun 2026 05:11:18 +0200, Sergio Paracuellos
> <sergio.paracuellos@xxxxxxxxx> said:
> > The GPIO controller's registers are organized as sets of eight 32-bit
> > registers with each set controlling a bank of up to 32 pins. A single
> > interrupt is shared for all of the banks handled by the controller.
> > The driver implements this using three gpio chip instances every one
> > with its own irq chip. Every single pin can generate interrupts having
> > a total of 96 possible interrupts here. It looks like there is a problem
> > with interrupts being properly mapped to the gpio bank using this solution.
> > This problem report is in the following lore's link [0].
> >
> > Device tree is using two cells for this, so only the interrupt pin and the
> > interrupt type are described there. Changing to have three cells to setup
> > also the bank and implement 'of_node_instance_match()' would also work but
> > this would be an ABI breakage and also a bit incoherent since gpios itself
> > are also using two cells and properly mapped in desired bank using through
> > its pin number on 'of_xlate()'.
> >
> > That said, register a linear IRQ domain of the total of 96 interrupts shared
> > with the three gpio chip instances so the bank and the interrupt is properly
> > decoded and devices using gpio IRQs properly work.
> >
> > [0]: https://lore.kernel.org/linux-gpio/CAAMcf8C_A9dJ_v4QRKtb9eGNOpJ7BZNOGsFP4i2WFOZxOVBPnQ@xxxxxxxxxxxxxx/T/#u
> >
> > Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
> > Co-developed-by: Vicente Bergas <vicencb@xxxxxxxxx>
> > Signed-off-by: Vicente Bergas <vicencb@xxxxxxxxx>
> > Tested-by: Vicente Bergas <vicencb@xxxxxxxxx>
> > Signed-off-by: Sergio Paracuellos <sergio.paracuellos@xxxxxxxxx>
> > ---
>
> This looks relatively good to me. Sashiko points out several issues in remove
> path but they're not different from what many other drivers suffer from so I'm
> willing to let it slip with the potential of fixing it treewide later.
>
> I won't be sending it for v7.1, it's way too big for rc7. I'll queue it directly
> for v7.2 and send it next week with my merge window PR.

Understood, thanks for letting me know.

Best regards,
    Sergio Paracuellos

>
> Bart