[RFC v11 0/4] PolarFire SoC GPIO interrupt support
Linus Walleij
linusw at kernel.org
Mon Mar 2 01:47:38 PST 2026
Hi Conor,
On Fri, Feb 27, 2026 at 3:53 PM Conor Dooley <conor at kernel.org> wrote:
> From: Conor Dooley <conor.dooley at microchip.com>
>
> In 2024 I sent a v7 of adding support for the GPIOs on PolarFire SoC,
> which relied on an irqchip driver for a mux sitting between the GPIO
> controllers and the main interrupt controller on the chip:
> https://lore.kernel.org/all/20240723-flatworm-cornflake-8023212f6584@wendy/
>
> Some feedback I got from Thomas there ended up being a complete black
> hole for time spent, and I never managed to make the change he wanted,
> as a house of cards collapsed whenever I tried it. I eventually
> abandoned my attempt to upstream the GPIO driver with interrupt support
> and cut it out of the driver to make progress. I've been carrying what
> Thomas deemed incorrect downstream since.
>
> Recently Hervé upstreamed a patchset for a Renesas chip that deals with
> a mux sitting between a GPIO controller and the platform interrupt
> controller by way of interrupt-map. I saw the opportunity to copy what
> he did, so have gone from an irqchip driver that read the mux setting
> that firmware had configured, to trivial driver that reads the mux
> configuration from devicetree and sets the hardware up to match.
>
> This gets rid entirely of the irqchip driver, so resolves Thomas'
> complaint, but I don't love how the GPIO side of things turned out quite
> as much. The hardware has 41 interrupts but 70 GPIO lines. 38 of these
> are 1:1, direct connections to a dedicated line on the interrupt
> controller and 3 are shared.
> With the parent mux driver, the GPIO driver's interrupt handler was only
> called either for specific direct interrupt or for only the subset that
> are fed into the shared interrupt for that controller. Without the
> parent irqchip from mux driver, and using interrupt-map, I lost the
> ability to use mux driver to selectively call the handler, so now the
> GPIO controller attempts to handle interrupts on all lines.
> Probably this is ultimately not a big deal, it just feels bad to do.
>
> Going RFC here, since it's an entirely different approach. The version
> number is a continuation from before, since the patchset linked above
> got merged at v10 when I stripped the interrupt support.
>
> The mux driver has moved from irqchip to soc, since that's where Hervé's
> ended up.
This surely looks acceptable, I had an inquiry about using proper
chaining for the IRQs but other than that it looks fine to me.
Yours,
Linus Walleij
More information about the linux-riscv
mailing list