linux-kernel - Re: [PATCH v5 7/8] soc: renesas: Add support for Renesas RZ/N1 GPIO Interrupt Multiplexer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdWY=FbO6YG1jrd0OWfrpPpBzrqmBVcWnw7TnnsKPGgr8A@mail.gmail.com>
Date: Thu, 23 Oct 2025 13:30:53 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Wolfram Sang <wsa+renesas@...g-engineering.com>, 
	Hoan Tran <hoan@...amperecomputing.com>, Linus Walleij <linus.walleij@...aro.org>, 
	Bartosz Golaszewski <brgl@...ev.pl>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Magnus Damm <magnus.damm@...il.com>, Saravana Kannan <saravanak@...gle.com>, 
	Serge Semin <fancer.lancer@...il.com>, Phil Edworthy <phil.edworthy@...esas.com>, 
	linux-gpio@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org, 
	Pascal Eberhard <pascal.eberhard@...com>, Miquel Raynal <miquel.raynal@...tlin.com>, 
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH v5 7/8] soc: renesas: Add support for Renesas RZ/N1 GPIO
 Interrupt Multiplexer

Hi Hervé,

On Wed, 22 Oct 2025 at 15:03, Herve Codina <herve.codina@...tlin.com> wrote:
> On Tue, 21 Oct 2025 15:05:35 +0200
> Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > On Mon, 20 Oct 2025 at 10:08, Herve Codina (Schneider Electric)
> > <herve.codina@...tlin.com> wrote:
> > > On the Renesas RZ/N1 SoC, GPIOs can generate interruptions. Those
> > > interruption lines are multiplexed by the GPIO Interrupt Multiplexer in
> > > order to map 32 * 3 GPIO interrupt lines to 8 GIC interrupt lines.
> > >
> > > The GPIO interrupt multiplexer IP does nothing but select 8 GPIO
> > > IRQ lines out of the 96 available to wire them to the GIC input lines.
> > >
> > > Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@...tlin.com>

> > > --- /dev/null
> > > +++ b/drivers/soc/renesas/rzn1_irqmux.c
> > > @@ -0,0 +1,150 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * RZ/N1 GPIO Interrupt Multiplexer
> > > + *
> > > + * Copyright 2025 Schneider Electric
> > > + * Author: Herve Codina <herve.codina@...tlin.com>
> > > + */
> > > +
> > > +#include <linux/bitops.h>
> > > +#include <linux/build_bug.h>
> > > +#include <linux/mod_devicetable.h>
> > > +#include <linux/module.h>
> > > +#include <linux/of.h>
> > > +#include <linux/of_irq.h>
> > > +#include <linux/platform_device.h>
> > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > +
> > > +/*
> > > + * The array index is the output line index, the value at the index is the
> > > + * GIC SPI interrupt number the output line is connected to.
> > > + */
> > > +static const u32 rzn1_irqmux_output_lines[] = {
> > > +       103, 104, 105, 106, 107, 108, 109, 110
> > > +};
> >
> > I did read the discussion with Wolfram, but the flexibility (and
> > overhead) provided by this array sounds a bit overkill to me.
> >
> > What about just defining:
> >
> >     #define RZN1_IRQMUX_SPI_BASE    103
> >     #define RZN1_IRQMUX_NUM_IRQS    8
> >
> > ?
> >
> > If/when a new SoC with a similar setup ever arrives, you can probably
> > just replace the constants above by variables inside SoC-specific
> > match data.  And if the new mapping would be non-contiguous, you can
> > still revive this array ;-)
>
> I have in mind a use case that can lead to a non-contiguous mapping.
>
> The RZ/N1 SoC embeds a Cortex-M3 CPU. This CPU can use GPIOs and
> some of them for interrupt purpose. In that case, those GPIOs have
> to be routed to the interrupt line expected by the Cortex-M3.
>
> And so, we have some interrupts reserved for CPUs running Linux and
> some others for the Cortex-M3.
>
> Among those reserved interrupts may some are not used.
>
> for instance:
>   Interrupt 103, 102: Reserved and used by Linux
>   Interrupt 103: Reserved for Linux but not used -> Hole in the mapping
>   Interrupt 104: Reserved and used my Cortex-M3 (need to be routed by Linux)

102 does not seem to  be correct?

> I don't know if this use case is relevant but I think we should be too restrictive
> on the mapping and so accept holes.
>
> With that in mind, I let you confirm that you still prefer to have a mapping
> without any holes. A future patch to support that is always possible.

While that would indeed be a non-discontiguous mapping, I do not see how
it is related to rzn1_irqmux_output_lines[] in the driver.  That array
would still contain the same contiguous values 103..110, right?

Sorry, I haven't been following the development of this driver that
closely (RZ/N1 is completely different from e.g. R-Car, and I never
had access to an RZ/N1 platform), so perhaps I am missing something.
Why does the user have to specify an interrupt-map in DT? Can't the
driver create the mapping dynamically, based actual usage of the
GPIOs? I.e. the first 8 GPIOs that ask for interrupt functionality
receive it, and are mapped to an available GIC interrupt?
I believe this is how rzg2l-irqc works, mapping up to 32 GPIO interrupts
to 32 GIC (TINT) interrupts.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds