Hi,

This series adds support for GPIO and GPIO IRQ mux available in the
RZ/N1 SoCs.

The first patches in this series are related to a new helper introduced
to parse an interrupt-map property.
  - patch 1: Introduce the helper (for_each_of_imap_item)
  - patch 2: Add a unittest for the new helper
  - patch 3 and 4: convert existing drivers to use this new helper

Patch 5 adds support for GPIO (device-tree description)

The last patches (6, 7 and 8) of the series are related to GPIO
interrupts and GPIO IRQ multiplexer.

In the RZ/N1 SoCs, GPIO interrupts are wired to a GPIO IRQ multiplexer.

This multiplexer does nothing but select 8 GPIO IRQ lines out of the 96
available to wire them to the GIC input lines.

One upstreaming attempt have been done previously by Phil Edworthy [1]
but the series has never been applied.

Based on my understanding, I have fully reworked the driver proposed by
Phil and removed the IRQ domain. Indeed, the device doesn't handle
interrupts. It just routes signals.

Also, as an interrupt-map property is used, the driver cannot be
involved as an interrupt controller itself. It is a nexus node.

With that in mind,
  - Patch 6 is related to the irq-mux binding.

  - Patch 7 introduces the irq-mux driver.
    This driver uses the 'for_each_of_imap_item' helper introduced
    previously. Indeed, the lines routing is defined by the
    interrupt-map property and the driver needs to set registers to
    apply this routing.

  - Patch 8 is the RZ/N1 device-tree description update to have the
    support for the GPIO interrupts.

[1] https://lore.kernel.org/all/20190219155511.28507-1-phil.edworthy@renesas.com/

Best regards,
Hervé

Changes v6 -> v7
  v6: https://lore.kernel.org/all/20251027123601.77216-1-herve.codina@bootlin.com/

  Rebase on top of v6.19-rc1.

  Patches 1 to 4 :
   - Add 'Reviewed-by: Linus Walleij'.

  Patch 5:
   - Fix a typo (Synopsys) in commit log.
   - GPIO controllers enabled by default.
   - Move "reg" just below "compatible".
   - Add 'Reviewed-by: Linus Walleij'.
   - Add 'Reviewed-by: Geert Uytterhoeven'.

  Patch 6:
   - Add 'Reviewed-by: Linus Walleij'.
   - Add 'Reviewed-by: Geert Uytterhoeven'.

  Patch 7:
   - Enable RZN1_IRQMUX only if GPIO_DWAPB is enabled.
   - Move a 'if' condition to a single line.
   - Print the output line index in the 'already defined' error message.
   - Move rzn1_irqmux_setup() code directly into rzn1_irqmux_probe().
   - Add 'Reviewed-by: Linus Walleij'.
   - Add 'Tested-by: Wolfram Sang'.
   - Add 'Reviewed-by: Wolfram Sang'.
   - Add 'Reviewed-by: Geert Uytterhoeven'.

  Patch 8:
   - Remove unneeded spaces.
   - Add 'Reviewed-by: Linus Walleij'
   - Add 'Reviewed-by: Wolfram Sang'
   - Add 'Reviewed-by: Geert Uytterhoeven'

Changes v5 -> v6
  v5: https://lore.kernel.org/lkml/20251020080648.13452-1-herve.codina@bootlin.com/

  Patches 1 and 2:
    Add 'Reviewed-by: Rob Herring'

  Patches 3, and 5:
    No changes

  Patch 6:
    Add 'Reviewed-by: Rob Herring'

  Patch 7:
    Remove an unneeded TAB in Makefile.
    Use RZN1_IRQMUX_GIC_SPI_BASE and RZN1_IRQMUX_NUM_OUTPUTS to replace
    the irq/output mapping table.
    Use DECLARE_BITMAP().

  Patch 8:
    No changes

Changes v4 -> v5
  v4: https://lore.kernel.org/lkml/20250922152640.154092-1-herve.codina@bootlin.com/

  Rebase on top of v6.18-rc1

  Patches 1 to 3:
    No changes

  Patch 4:
    Fix conflict.
    Add 'Tested-by: Wolfram Sang'.

  Patch 5:
    Add 'Reviewed-by: Bartosz Golaszewski'.

  Patch 6:
    Add 'Reviewed-by: Wolfram Sang'.

  Patch 7:
    Add a missing 'const' qualifier.
    Remove an unneeded dev_err_probe() call.
    Add a check to avoid setting the same output line multiple times.

  Patch 8:
    Update comment
    Add 'Reviewed-by: Bartosz Golaszewski'

Changes v3 -> v4
  v3: https://lore.kernel.org/lkml/20250918104009.94754-1-herve.codina@bootlin.com/

  Patch 1:
    - Add 'Tested-by: Wolfram Sang'

  Patch 2..5:
    - No changes

  Patch 6:
    - Add minItems and maxItems
    - Update the 'interrup-map' description

  Patch 7:
    - Use rzn1_irqmux prefix instead of irqmux.
    - Introduce rzn1_irqmux_output_lines[] to give the mapping between
      the interrupt output line index and the GIC controller interrupt
      number.
    - Remove of_irq_count() call and related checks

  Patch 8:
    - Describe the irq mux node using a reduced (one item) interrupt-map
      property.

Changes v2 -> v3
  v2: https://lore.kernel.org/lkml/20250909120041.154459-1-herve.codina@bootlin.com/

  Reordered patches as suggested by Thomas Gleixner.

  Patch 1: (3 in v2)
    - Replace a wrong 'extern' by 'static inline' in of_irq.h  (detected
      by test robots)

  Patch 2: (4 in v2)
  Patch 3: (5 in v2)
  Patch 4: (6 in v2)
    - No changes

  Patch 5: (1 in v2)
    - Add 'Reviewed-by: Wolfram Sang'
    - Add 'Tested-by: Wolfram Sang'

  Patch 6: (2 in v2)
    - Add '#address-cells = <0>;' in the interrupt-controller node
      present in the example.

  Patch 7:
  Patch 8:
    - No changes

Changes v1 -> v2
  v1: https://lore.kernel.org/lkml/20250725152618.32886-1-herve.codina@bootlin.com/

  Rebase on top of v6.17-rc5

  Patch 1 in v1
    - Removed in v2 (no need for RZ/N1 compatible strings).

  Patch 1 (2 in v1)
    - Fix node names (issue reported by Rob's bot)
    - Fix compatible RZ/N1 compatible strings
    - Removed undocumented and unused 'bank-name' properties

  Patch 2 (3 in v1)
   - Remove 'interrupts' property
   - Update 'interrupt-map' description

  Patch 3 (4 in v1)
   - Rework of_irq_foreach_imap() to provide the for_each_of_imap_item
     iterator (similar to for_each_of_range)

  Patch 4 (new in v2)
   - Add a unittest for for_each_of_imap_item

  Patch 5 (new in v2)
   - Convert irqchip/ls-extirq to use for_each_of_imap_item

  Patch 6 (new in v2)
   - Convert irqchip/renesas-rza1 to use for_each_of_imap_item

  Patch 7 (5 in v1)
   - Use for_each_of_imap_item
   - Remove 'interrupts' property usage

  Patch 8 (6 in v1)
   - Remove 'interrupts' property

Herve Codina (Schneider Electric) (8):
  of/irq: Introduce for_each_of_imap_item
  of: unittest: Add a test case for for_each_of_imap_item iterator
  irqchip/ls-extirq: Use for_each_of_imap_item iterator
  irqchip/renesas-rza1: Use for_each_of_imap_item iterator
  ARM: dts: r9a06g032: Add GPIO controllers
  dt-bindings: soc: renesas: Add the Renesas RZ/N1 GPIO Interrupt
    Multiplexer
  soc: renesas: Add support for Renesas RZ/N1 GPIO Interrupt Multiplexer
  ARM: dts: r9a06g032: Add support for GPIO interrupts

 .../soc/renesas/renesas,rzn1-gpioirqmux.yaml  |  87 ++++++++++
 arch/arm/boot/dts/renesas/r9a06g032.dtsi      | 159 ++++++++++++++++++
 drivers/irqchip/irq-ls-extirq.c               |  47 ++----
 drivers/irqchip/irq-renesas-rza1.c            |  43 ++---
 drivers/of/irq.c                              |  70 ++++++++
 .../of/unittest-data/tests-interrupts.dtsi    |   9 +
 drivers/of/unittest.c                         | 116 +++++++++++++
 drivers/soc/renesas/Kconfig                   |   4 +
 drivers/soc/renesas/Makefile                  |   1 +
 drivers/soc/renesas/rzn1_irqmux.c             | 127 ++++++++++++++
 include/linux/of_irq.h                        |  41 ++++-
 11 files changed, 646 insertions(+), 58 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/soc/renesas/renesas,rzn1-gpioirqmux.yaml
 create mode 100644 drivers/soc/renesas/rzn1_irqmux.c

-- 
2.52.0

Hi everyone,

> This series adds support for GPIO and GPIO IRQ mux available in the
> RZ/N1 SoCs.
> 
> The first patches in this series are related to a new helper introduced
> to parse an interrupt-map property.
>   - patch 1: Introduce the helper (for_each_of_imap_item)
>   - patch 2: Add a unittest for the new helper
>   - patch 3 and 4: convert existing drivers to use this new helper
> 
> Patch 5 adds support for GPIO (device-tree description)
> 
> The last patches (6, 7 and 8) of the series are related to GPIO
> interrupts and GPIO IRQ multiplexer.

I think this series is ready and I would really like to see it upstream
soon. I wonder, however, if the path to upstream has already been
discussed? It touches various subsystems, so I don't see immediately who
should pick the whole series? Or if parts should go to different
subsystems offering immutable branches? I bring this up because I want
to avoid losing a cycle just because this is unclear...

Happy hacking,

   Wolfram

Hi Wolfram, Rob, Thomas,

On Sat, 20 Dec 2025 at 07:37, Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> > This series adds support for GPIO and GPIO IRQ mux available in the
> > RZ/N1 SoCs.
> >
> > The first patches in this series are related to a new helper introduced
> > to parse an interrupt-map property.
> >   - patch 1: Introduce the helper (for_each_of_imap_item)
> >   - patch 2: Add a unittest for the new helper
> >   - patch 3 and 4: convert existing drivers to use this new helper
> >
> > Patch 5 adds support for GPIO (device-tree description)
> >
> > The last patches (6, 7 and 8) of the series are related to GPIO
> > interrupts and GPIO IRQ multiplexer.
>
> I think this series is ready and I would really like to see it upstream
> soon. I wonder, however, if the path to upstream has already been
> discussed? It touches various subsystems, so I don't see immediately who
> should pick the whole series? Or if parts should go to different
> subsystems offering immutable branches? I bring this up because I want
> to avoid losing a cycle just because this is unclear...

We actually did[1]. Unfortunately that plan was never executed.
The DTS patches I can easily take through renesas-devel, as they have
no hard dependencies.
For the remaining patches, I see two options:
  A. Rob takes the first two patches, and provides an immutable branch.
     Then Thomas takes the irqchip patches, and I take the rest.
  B. Rob and Thomas provide acks, and I take the whole series.

Thanks!

[1] https://lore.kernel.org/20251114124045.16204839@bootlin.com

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

> > I think this series is ready and I would really like to see it upstream
> > soon. I wonder, however, if the path to upstream has already been
> > discussed? It touches various subsystems, so I don't see immediately who
> > should pick the whole series? Or if parts should go to different
> > subsystems offering immutable branches? I bring this up because I want
> > to avoid losing a cycle just because this is unclear...
> 
> We actually did[1]. Unfortunately that plan was never executed.
> The DTS patches I can easily take through renesas-devel, as they have
> no hard dependencies.
> For the remaining patches, I see two options:
>   A. Rob takes the first two patches, and provides an immutable branch.
>      Then Thomas takes the irqchip patches, and I take the rest.
>   B. Rob and Thomas provide acks, and I take the whole series.

B) should be the easiest for everyone. Rob, Thomas, are you okay to ack
these patches? If no reply here, maybe a resend is in place with proper
description of the suggested path upstream in the cover letter?