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@bootlin.com>
---
 drivers/soc/renesas/Kconfig       |   4 ++
 drivers/soc/renesas/Makefile      |   1 +
 drivers/soc/renesas/rzn1_irqmux.c | 110 ++++++++++++++++++++++++++++++
 3 files changed, 115 insertions(+)
 create mode 100644 drivers/soc/renesas/rzn1_irqmux.c

diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 719b7f4f376f..0878b6884515 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -58,6 +58,7 @@ config ARCH_RZN1
 	select PM
 	select PM_GENERIC_DOMAINS
 	select ARM_AMBA
+	select RZN1_IRQMUX
 
 if ARM && ARCH_RENESAS
 
@@ -447,6 +448,9 @@ config PWC_RZV2M
 config RST_RCAR
 	bool "Reset Controller support for R-Car" if COMPILE_TEST
 
+config RZN1_IRQMUX
+	bool "Renesas RZ/N1 GPIO IRQ multiplexer support" if COMPILE_TEST
+
 config SYSC_RZ
 	bool "System controller for RZ SoCs" if COMPILE_TEST
 
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 3bdcc6a395d5..daa932c7698d 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -14,4 +14,5 @@ obj-$(CONFIG_SYS_R9A09G057)	+= r9a09g057-sys.o
 # Family
 obj-$(CONFIG_PWC_RZV2M)		+= pwc-rzv2m.o
 obj-$(CONFIG_RST_RCAR)		+= rcar-rst.o
+obj-$(CONFIG_RZN1_IRQMUX)		+= rzn1_irqmux.o
 obj-$(CONFIG_SYSC_RZ)		+= rz-sysc.o
diff --git a/drivers/soc/renesas/rzn1_irqmux.c b/drivers/soc/renesas/rzn1_irqmux.c
new file mode 100644
index 000000000000..3855e132c15f
--- /dev/null
+++ b/drivers/soc/renesas/rzn1_irqmux.c
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * RZ/N1 GPIO Interrupt Multiplexer
+ *
+ * Copyright 2025 Schneider Electric
+ * Author: Herve Codina <herve.codina@bootlin.com>
+ */
+
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+
+#define IRQMUX_MAX_IRQS 8
+
+static int irqmux_setup(struct device *dev, struct device_node *np, u32 __iomem *regs)
+{
+	struct of_imap_parser imap_parser;
+	struct of_imap_item imap_item;
+	unsigned int index = 0;
+	u32 tmp;
+	int ret;
+
+	/* We support only #interrupt-cells = <1> and #address-cells = <0> */
+	ret = of_property_read_u32(np, "#interrupt-cells", &tmp);
+	if (ret)
+		return ret;
+	if (tmp != 1)
+		return -EINVAL;
+
+	ret = of_property_read_u32(np, "#address-cells", &tmp);
+	if (ret)
+		return ret;
+	if (tmp != 0)
+		return -EINVAL;
+
+	ret = of_imap_parser_init(&imap_parser, np, &imap_item);
+	if (ret)
+		return ret;
+
+	for_each_of_imap_item(&imap_parser, &imap_item) {
+		/*
+		 * The child #address-cells is 0 (already checked). The first
+		 * value in imap item is the src hwirq.
+		 *
+		 * imap items matches 1:1 the interrupt lines that could
+		 * be configured by registers (same order, same number).
+		 * Configure the related register with the src hwirq retrieved
+		 * from the interrupt-map.
+		 */
+		if (index > IRQMUX_MAX_IRQS) {
+			of_node_put(imap_item.parent_args.np);
+			dev_err(dev, "too much items in interrupt-map\n");
+			return -EINVAL;
+		}
+
+		writel(imap_item.child_imap[0], regs + index);
+		index++;
+	}
+
+	return 0;
+}
+
+static int irqmux_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	u32 __iomem *regs;
+	int nr_irqs;
+	int ret;
+
+	regs = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(regs))
+		return PTR_ERR(regs);
+
+	nr_irqs = of_irq_count(np);
+	if (nr_irqs < 0)
+		return nr_irqs;
+
+	if (nr_irqs > IRQMUX_MAX_IRQS) {
+		dev_err(dev, "too many output interrupts\n");
+		return -ENOENT;
+	}
+
+	ret = irqmux_setup(dev, np, regs);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to setup mux\n");
+
+	return 0;
+}
+
+static const struct of_device_id irqmux_of_match[] = {
+	{ .compatible = "renesas,rzn1-gpioirqmux", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, irq_mux_of_match);
+
+static struct platform_driver irqmux_driver = {
+	.probe = irqmux_probe,
+	.driver = {
+		.name = "rzn1_irqmux",
+		.of_match_table = irqmux_of_match,
+	},
+};
+module_platform_driver(irqmux_driver);
+
+MODULE_AUTHOR("Herve Codina <herve.codina@bootlin.com>");
+MODULE_DESCRIPTION("Renesas RZ/N1 GPIO IRQ Multiplexer Driver");
+MODULE_LICENSE("GPL");
-- 
2.51.0

Hi Hervé,

On Thu, 18 Sept 2025 at 12:40, Herve Codina (Schneider Electric)
<herve.codina@bootlin.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@bootlin.com>

Thanks for your patch!

> --- /dev/null
> +++ b/drivers/soc/renesas/rzn1_irqmux.c

> +static const struct of_device_id irqmux_of_match[] = {
> +       { .compatible = "renesas,rzn1-gpioirqmux", },
> +       { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, irq_mux_of_match);
                           ^^^^^^^^^^^^^^^^
                           irqmux_of_match

Interestingly, this built fine for me before, presumably until commit
5ab23c7923a1d2ae ("modpost: Create modalias for builtin modules")
in v6.18-rc1.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

> > +static const struct of_device_id irqmux_of_match[] = {
> > +       { .compatible = "renesas,rzn1-gpioirqmux", },
> > +       { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, irq_mux_of_match);
>                            ^^^^^^^^^^^^^^^^
>                            irqmux_of_match
> 
> Interestingly, this built fine for me before, presumably until commit
> 5ab23c7923a1d2ae ("modpost: Create modalias for builtin modules")
> in v6.18-rc1.

This should be fixed in v4 already as a side effect of my request for a
better namespace prefix.

Hi Wolfram,

On Tue, 14 Oct 2025 at 16:11, Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> > > +static const struct of_device_id irqmux_of_match[] = {
> > > +       { .compatible = "renesas,rzn1-gpioirqmux", },
> > > +       { /* sentinel */ }
> > > +};
> > > +MODULE_DEVICE_TABLE(of, irq_mux_of_match);
> >                            ^^^^^^^^^^^^^^^^
> >                            irqmux_of_match
> >
> > Interestingly, this built fine for me before, presumably until commit
> > 5ab23c7923a1d2ae ("modpost: Create modalias for builtin modules")
> > in v6.18-rc1.
>
> This should be fixed in v4 already as a side effect of my request for a
> better namespace prefix.

Thanks! Sorry, I really thought I had the latest version in my tree...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

Hi Herve,

> +#define IRQMUX_MAX_IRQS 8
> +
> +static int irqmux_setup(struct device *dev, struct device_node *np, u32 __iomem *regs)

The whole driver would benefit from a 'rzn1_irqmux' instead of 'irqmux'
prefix, I'd say.

> +	for_each_of_imap_item(&imap_parser, &imap_item) {
> +		/*
> +		 * The child #address-cells is 0 (already checked). The first
> +		 * value in imap item is the src hwirq.
> +		 *
> +		 * imap items matches 1:1 the interrupt lines that could
> +		 * be configured by registers (same order, same number).
> +		 * Configure the related register with the src hwirq retrieved
> +		 * from the interrupt-map.
> +		 */

I haven't looked into the above for_each_of_imap_item-helper. But
wouldn't it be possibleto retrieve the GIC_SPI number as well and use
the correct register based on that? That would remove the need of an
already sorted interrupt-map.

> +		if (index > IRQMUX_MAX_IRQS) {
> +			of_node_put(imap_item.parent_args.np);
> +			dev_err(dev, "too much items in interrupt-map\n");
> +			return -EINVAL;

-E2BIG? With such a unique errno, we could even drop the dev_err.

> +		}
> +
> +		writel(imap_item.child_imap[0], regs + index);
> +		index++;
> +	}
> +
> +	return 0;
> +}
> +
> +static int irqmux_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device_node *np = dev->of_node;
> +	u32 __iomem *regs;
> +	int nr_irqs;
> +	int ret;
> +
> +	regs = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(regs))
> +		return PTR_ERR(regs);
> +
> +	nr_irqs = of_irq_count(np);
> +	if (nr_irqs < 0)
> +		return nr_irqs;
> +
> +	if (nr_irqs > IRQMUX_MAX_IRQS) {
> +		dev_err(dev, "too many output interrupts\n");
> +		return -ENOENT;

-E2BIG? Wait, isn't this the same check twice?

Thanks for this work,

   Wolfram

Hi Wolfram,

On Fri, 19 Sep 2025 11:41:39 +0200
Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:

> Hi Herve,
> 
> > +#define IRQMUX_MAX_IRQS 8
> > +
> > +static int irqmux_setup(struct device *dev, struct device_node *np, u32 __iomem *regs)  
> 
> The whole driver would benefit from a 'rzn1_irqmux' instead of 'irqmux'
> prefix, I'd say.

Agree, I will used the 'rzn1_irqmux' prefix.

> 
> > +	for_each_of_imap_item(&imap_parser, &imap_item) {
> > +		/*
> > +		 * The child #address-cells is 0 (already checked). The first
> > +		 * value in imap item is the src hwirq.
> > +		 *
> > +		 * imap items matches 1:1 the interrupt lines that could
> > +		 * be configured by registers (same order, same number).
> > +		 * Configure the related register with the src hwirq retrieved
> > +		 * from the interrupt-map.
> > +		 */  
> 
> I haven't looked into the above for_each_of_imap_item-helper. But
> wouldn't it be possibleto retrieve the GIC_SPI number as well and use
> the correct register based on that? That would remove the need of an
> already sorted interrupt-map.

Hum, this give the knowledge of the GIC interrupt number in the driver itself.

Not sure that the mapping between the output interrupt line number N (handled
by register index N) and the GIC interrupt number X should be hardcoded in
the driver.

In my v1 series iteration, I used the 'interrupts' property to provide this
missing information:
   interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, /* line 0 (reg index 0) route to GIC 103 */
                <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>, /* line 1 (reg index 1) route to GIC 104 */
                <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>, /* line 2 (reg index 2) route to GIC 105 */
                ...

Base on the interrupts table and the interrupt-map, I deduce the reg index:
  - From interrupt-map, got a GIC interrupt number
  - From interrupts table and the GIC interrupt number, got the line/reg index.

Rob asked to use only interrupt-map and use directly the interrupt-map index as
the hardware index:
  https://lore.kernel.org/lkml/20250801111753.382f52ac@bootlin.com/

> 
> > +		if (index > IRQMUX_MAX_IRQS) {
> > +			of_node_put(imap_item.parent_args.np);
> > +			dev_err(dev, "too much items in interrupt-map\n");
> > +			return -EINVAL;  
> 
> -E2BIG? With such a unique errno, we could even drop the dev_err.

Yes sure.

> 
> > +		}
> > +
> > +		writel(imap_item.child_imap[0], regs + index);
> > +		index++;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int irqmux_probe(struct platform_device *pdev)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct device_node *np = dev->of_node;
> > +	u32 __iomem *regs;
> > +	int nr_irqs;
> > +	int ret;
> > +
> > +	regs = devm_platform_ioremap_resource(pdev, 0);
> > +	if (IS_ERR(regs))
> > +		return PTR_ERR(regs);
> > +
> > +	nr_irqs = of_irq_count(np);
> > +	if (nr_irqs < 0)
> > +		return nr_irqs;
> > +
> > +	if (nr_irqs > IRQMUX_MAX_IRQS) {
> > +		dev_err(dev, "too many output interrupts\n");
> > +		return -ENOENT;  
> 
> -E2BIG? Wait, isn't this the same check twice?

This is not the same check but this one should not be there.

Indeed of_irq_count() counts the number of items available in the
'interrupts' property. This is not used anymore.

I missed to remove it from v1 to v2 updates (and also from v2 to v3).

The of_irq_count() call and related checks will be remove in the next
iteration.

Best regards,
Hervé

> Rob asked to use only interrupt-map and use directly the interrupt-map index as
> the hardware index:
>   https://lore.kernel.org/lkml/20250801111753.382f52ac@bootlin.com/

I agree with that. Currently an interrupt-map entry looks like:

	interrupt-map = <0 &gic GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,

And the number after GIC_SPI determines the index register, no? Can't we
simply say 'index = <SPI_nr_from_dt> - 103' incl. some sanity checks?

Hi Wolfram,

On Fri, 19 Sep 2025 16:40:06 +0200
Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:

> > Rob asked to use only interrupt-map and use directly the interrupt-map index as
> > the hardware index:
> >   https://lore.kernel.org/lkml/20250801111753.382f52ac@bootlin.com/  
> 
> I agree with that. Currently an interrupt-map entry looks like:
> 
> 	interrupt-map = <0 &gic GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
> 
> And the number after GIC_SPI determines the index register, no? Can't we
> simply say 'index = <SPI_nr_from_dt> - 103' incl. some sanity checks?
> 

And so 103 used to compute the index is hardcoded on the driver.

Further more the wiring of irq-mux interrupt output to the GIC input
line depends on the irq-mux integration and not the irq-mux itself.
Nothing in the irq-mux itself requires a specific connection to the
GIC.

But well, without adding this mapping information in the DT, maybe a
table in the driver in order to determine reg index from GIC IRQ number.

kind of:
  static u8 reg_index[8] = {103, 104, 105, ... , 110};

Base on GIC IRQ number retrieve from the interrupt-map item, we search for
the index in reg_index that match this number. The index found is the index
used to access the register.

What do you think about this?

Best regards,
Hervé

> kind of:
>   static u8 reg_index[8] = {103, 104, 105, ... , 110};
> 
> Base on GIC IRQ number retrieve from the interrupt-map item, we search for
> the index in reg_index that match this number. The index found is the index
> used to access the register.
> 
> What do you think about this?

I sure like it better than a fixed ordering in DT. And the advantage
compared to subtracting 103 is that reg_index can be flexible in case we
want to support other SoCs than RZ/N1?