[RFC,1/5] dt-bindings: interrupt-controller: renesas,rzg2l-irqc: Document RZ/G2UL SoC

Commit Message

Lad, Prabhakar Nov. 7, 2022, 5:53 p.m. UTC

From: Lad Prabhakar <[e-mail]>

Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is
identical to one found on the RZ/G2L SoC. No driver changes are
required as generic compatible string "renesas,rzg2l-irqc" will be
used as a fallback.

Signed-off-by: Lad Prabhakar <[e-mail]>
---
Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five
- G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt
domain) -> RISCV INTC
- On the RZ/Five we have additional registers for IRQC block
- On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC
---
 .../bindings/interrupt-controller/renesas,rzg2l-irqc.yaml        | 1 +
 1 file changed, 1 insertion(+)

Comments

Krzysztof Kozlowski Nov. 7, 2022, 6:39 p.m. UTC | #1

On 07/11/2022 18:53, Prabhakar wrote:
> From: Lad Prabhakar <[e-mail]>
> 
> Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is
> identical to one found on the RZ/G2L SoC. No driver changes are
> required as generic compatible string "renesas,rzg2l-irqc" will be
> used as a fallback.
> 
> Signed-off-by: Lad Prabhakar <[e-mail]>
> ---


Acked-by: Krzysztof Kozlowski <[e-mail]>

Best regards,
Krzysztof

Geert Uytterhoeven Nov. 17, 2022, 10:53 a.m. UTC | #2

Hi Prabhakar,

On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <[e-mail]> wrote:
> From: Lad Prabhakar <[e-mail]>
>
> Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is
> identical to one found on the RZ/G2L SoC. No driver changes are
> required as generic compatible string "renesas,rzg2l-irqc" will be
> used as a fallback.
>
> Signed-off-by: Lad Prabhakar <[e-mail]>

Thanks for your patch!

> ---
> Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five
> - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt
> domain) -> RISCV INTC

I think this difference is purely a software difference, and abstracted
in DTS through the interrupt hierarchy.
Does it have any impact on the bindings?

> - On the RZ/Five we have additional registers for IRQC block

Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus
warranting separate compatible values.

> - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC

Can you please elaborate? I may have missed something, but to me it
looks like that is exactly the same on RZ/G2UL and on RZ/Five.

> --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
> @@ -26,6 +26,7 @@ properties:
>    compatible:
>      items:
>        - enum:
> +          - renesas,r9a07g043u-irqc   # RZ/G2UL
>            - renesas,r9a07g044-irqc    # RZ/G2{L,LC}
>            - renesas,r9a07g054-irqc    # RZ/V2L
>        - const: renesas,rzg2l-irqc

Reviewed-by: Geert Uytterhoeven <[e-mail]>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [e-mail]

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

Lad, Prabhakar Nov. 17, 2022, 11:37 a.m. UTC | #3

Hi Geert,

Thank you for the review.

On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven
<[e-mail]> wrote:
>
> Hi Prabhakar,
>
> On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <[e-mail]> wrote:
> > From: Lad Prabhakar <[e-mail]>
> >
> > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is
> > identical to one found on the RZ/G2L SoC. No driver changes are
> > required as generic compatible string "renesas,rzg2l-irqc" will be
> > used as a fallback.
> >
> > Signed-off-by: Lad Prabhakar <[e-mail]>
>
> Thanks for your patch!
>
> > ---
> > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five
> > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt
> > domain) -> RISCV INTC
>
> I think this difference is purely a software difference, and abstracted
> in DTS through the interrupt hierarchy.
> Does it have any impact on the bindings?
>
For now I dont know for sure, as I havent started looking into it yet.

> > - On the RZ/Five we have additional registers for IRQC block
>
> Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus
> warranting separate compatible values.
>
\o/

> > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC
>
> Can you please elaborate? I may have missed something, but to me it
> looks like that is exactly the same on RZ/G2UL and on RZ/Five.
>
I completely missed rz/g2ul had this interrupt too.

Cheers,
Prabhakar

Lad, Prabhakar Nov. 18, 2022, 12:29 p.m. UTC | #4

Hi Geert,

On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven
<[e-mail]> wrote:
>
> Hi Prabhakar,
>
> On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <[e-mail]> wrote:
> > From: Lad Prabhakar <[e-mail]>
> >
> > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is
> > identical to one found on the RZ/G2L SoC. No driver changes are
> > required as generic compatible string "renesas,rzg2l-irqc" will be
> > used as a fallback.
> >
> > Signed-off-by: Lad Prabhakar <[e-mail]>
>
> Thanks for your patch!
>
> > ---
> > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five
> > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt
> > domain) -> RISCV INTC
>
> I think this difference is purely a software difference, and abstracted
> in DTS through the interrupt hierarchy.
> Does it have any impact on the bindings?
>
> > - On the RZ/Five we have additional registers for IRQC block
>
> Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus
> warranting separate compatible values.
>
> > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC
>
> Can you please elaborate? I may have missed something, but to me it
> looks like that is exactly the same on RZ/G2UL and on RZ/Five.
>
Now that we have to update the binding doc with the BUS_ERR_INT too,
do you think it would make sense to add interrupt-names too?

BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will
register a handler for it).

Cheers,
Prabhakar

Lad, Prabhakar Dec. 19, 2022, 12:57 p.m. UTC | #5

Hi Geert,

On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar
<[e-mail]> wrote:
>
> Hi Geert,
>
> On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven
> <[e-mail]> wrote:
> >
> > Hi Prabhakar,
> >
> > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <[e-mail]> wrote:
> > > From: Lad Prabhakar <[e-mail]>
> > >
> > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is
> > > identical to one found on the RZ/G2L SoC. No driver changes are
> > > required as generic compatible string "renesas,rzg2l-irqc" will be
> > > used as a fallback.
> > >
> > > Signed-off-by: Lad Prabhakar <[e-mail]>
> >
> > Thanks for your patch!
> >
> > > ---
> > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five
> > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt
> > > domain) -> RISCV INTC
> >
> > I think this difference is purely a software difference, and abstracted
> > in DTS through the interrupt hierarchy.
> > Does it have any impact on the bindings?
> >
> > > - On the RZ/Five we have additional registers for IRQC block
> >
> > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus
> > warranting separate compatible values.
> >
> > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC
> >
> > Can you please elaborate? I may have missed something, but to me it
> > looks like that is exactly the same on RZ/G2UL and on RZ/Five.
> >
> Now that we have to update the binding doc with the BUS_ERR_INT too,
> do you think it would make sense to add interrupt-names too?
>
> BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will
> register a handler for it).
>
Gentle ping.

Cheers,
Prabhakar

Geert Uytterhoeven Dec. 19, 2022, 1:50 p.m. UTC | #6

Hi Prabhakar,

On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar
<[e-mail]> wrote:
> On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar
> <[e-mail]> wrote:
> > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven
> > <[e-mail]> wrote:
> > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <[e-mail]> wrote:
> > > > From: Lad Prabhakar <[e-mail]>
> > > >
> > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is
> > > > identical to one found on the RZ/G2L SoC. No driver changes are
> > > > required as generic compatible string "renesas,rzg2l-irqc" will be
> > > > used as a fallback.
> > > >
> > > > Signed-off-by: Lad Prabhakar <[e-mail]>

> > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five
> > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt
> > > > domain) -> RISCV INTC
> > >
> > > I think this difference is purely a software difference, and abstracted
> > > in DTS through the interrupt hierarchy.
> > > Does it have any impact on the bindings?
> > >
> > > > - On the RZ/Five we have additional registers for IRQC block
> > >
> > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus
> > > warranting separate compatible values.
> > >
> > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC
> > >
> > > Can you please elaborate? I may have missed something, but to me it
> > > looks like that is exactly the same on RZ/G2UL and on RZ/Five.
> > >
> > Now that we have to update the binding doc with the BUS_ERR_INT too,
> > do you think it would make sense to add interrupt-names too?

> Gentle ping.

Thanks for the ping, I had missed you were waiting on input from me.
Sorry for that...

As there are three different groups of parent interrupts, adding
interrupt-names makes sense.  However, as this binding is already
in active use since v6.1, you probably need to keep on supporting the
ack of interrupt-names.  Or do you think there are no real users yet,
and we can drop support for that?

> > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will
> > register a handler for it).

Do you mean you will need a fourth parent type for that?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [e-mail]

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

Lad, Prabhakar Dec. 19, 2022, 2:25 p.m. UTC | #7

Hi Geert,

On Mon, Dec 19, 2022 at 1:50 PM Geert Uytterhoeven <[e-mail]> wrote:
>
> Hi Prabhakar,
>
> On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar
> <[e-mail]> wrote:
> > On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar
> > <[e-mail]> wrote:
> > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven
> > > <[e-mail]> wrote:
> > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <[e-mail]> wrote:
> > > > > From: Lad Prabhakar <[e-mail]>
> > > > >
> > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is
> > > > > identical to one found on the RZ/G2L SoC. No driver changes are
> > > > > required as generic compatible string "renesas,rzg2l-irqc" will be
> > > > > used as a fallback.
> > > > >
> > > > > Signed-off-by: Lad Prabhakar <[e-mail]>
>
> > > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five
> > > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt
> > > > > domain) -> RISCV INTC
> > > >
> > > > I think this difference is purely a software difference, and abstracted
> > > > in DTS through the interrupt hierarchy.
> > > > Does it have any impact on the bindings?
> > > >
> > > > > - On the RZ/Five we have additional registers for IRQC block
> > > >
> > > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus
> > > > warranting separate compatible values.
> > > >
> > > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC
> > > >
> > > > Can you please elaborate? I may have missed something, but to me it
> > > > looks like that is exactly the same on RZ/G2UL and on RZ/Five.
> > > >
> > > Now that we have to update the binding doc with the BUS_ERR_INT too,
> > > do you think it would make sense to add interrupt-names too?
>
> > Gentle ping.
>
> Thanks for the ping, I had missed you were waiting on input from me.
> Sorry for that...
>
No worries.

> As there are three different groups of parent interrupts, adding
> interrupt-names makes sense.
Ok.

> However, as this binding is already in active use since v6.1, you
> probably need to keep on supporting the
> ack of interrupt-names.  Or do you think there are no real users yet,
> and we can drop support for that?
>
Sorry can you please elaborate on "ack of interrupt-names".

So moving forward the driver will first check for interrupt-names
property and if that exists it will map the IRQ0-7 and GPIO-TINIT
interrupts (based on the names it will create a hierarchy domain) and
for the NMI and BUS_ERR_INT we request the IRQ numbers and register
the IRQ handler in IRQC driver itself.

And for backward compatibility we parse the IRQ numbers based on
indexes i.e. 0 = NMI, 1-8  = IRQ 0-7  and 9-41 GPIO TINT interrupts.

> > > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will
> > > register a handler for it).
>
> Do you mean you will need a fourth parent type for that?
>
No something like what we have for NMI we can add something similar
below for bus error interrupts:
interrupts = ....
              <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;
interrupt-names = ....,
             "bus-error-int";

As the registers to handle the NMI and BUS_ERR_INT are present on the
IRQC block, the interrupt handler will have to be registered by the
IRQC block itself by requesting the IRQ. So we will have to skip
mapping of BUS_ERR_INT as we do for the NMI case. Does that make
sense?

Cheers,
Prabhakar

Geert Uytterhoeven Dec. 19, 2022, 2:46 p.m. UTC | #8

Hi Prabhakar,

On Mon, Dec 19, 2022 at 3:26 PM Lad, Prabhakar
<[e-mail]> wrote:
> On Mon, Dec 19, 2022 at 1:50 PM Geert Uytterhoeven <[e-mail]> wrote:
> > On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar
> > <[e-mail]> wrote:
> > > On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar
> > > <[e-mail]> wrote:
> > > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven
> > > > <[e-mail]> wrote:
> > > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <[e-mail]> wrote:
> > > > > > From: Lad Prabhakar <[e-mail]>
> > > > > >
> > > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is
> > > > > > identical to one found on the RZ/G2L SoC. No driver changes are
> > > > > > required as generic compatible string "renesas,rzg2l-irqc" will be
> > > > > > used as a fallback.
> > > > > >
> > > > > > Signed-off-by: Lad Prabhakar <[e-mail]>
> >
> > > > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five
> > > > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt
> > > > > > domain) -> RISCV INTC
> > > > >
> > > > > I think this difference is purely a software difference, and abstracted
> > > > > in DTS through the interrupt hierarchy.
> > > > > Does it have any impact on the bindings?
> > > > >
> > > > > > - On the RZ/Five we have additional registers for IRQC block
> > > > >
> > > > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus
> > > > > warranting separate compatible values.
> > > > >
> > > > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC
> > > > >
> > > > > Can you please elaborate? I may have missed something, but to me it
> > > > > looks like that is exactly the same on RZ/G2UL and on RZ/Five.
> > > > >
> > > > Now that we have to update the binding doc with the BUS_ERR_INT too,
> > > > do you think it would make sense to add interrupt-names too?
> >
> > > Gentle ping.
> >
> > Thanks for the ping, I had missed you were waiting on input from me.
> > Sorry for that...
> >
> No worries.
>
> > As there are three different groups of parent interrupts, adding
> > interrupt-names makes sense.
> Ok.
>
> > However, as this binding is already in active use since v6.1, you
> > probably need to keep on supporting the
> > ack of interrupt-names.  Or do you think there are no real users yet,
> > and we can drop support for that?
> >
> Sorry can you please elaborate on "ack of interrupt-names".

Oops, s/ack/lack/. I.e. what you described below.

> So moving forward the driver will first check for interrupt-names
> property and if that exists it will map the IRQ0-7 and GPIO-TINIT
> interrupts (based on the names it will create a hierarchy domain) and
> for the NMI and BUS_ERR_INT we request the IRQ numbers and register
> the IRQ handler in IRQC driver itself.
>
> And for backward compatibility we parse the IRQ numbers based on
> indexes i.e. 0 = NMI, 1-8  = IRQ 0-7  and 9-41 GPIO TINT interrupts.

Exactly.

> > > > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will
> > > > register a handler for it).
> >
> > Do you mean you will need a fourth parent type for that?
> >
> No something like what we have for NMI we can add something similar
> below for bus error interrupts:
> interrupts = ....
>               <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;
> interrupt-names = ....,
>              "bus-error-int";

Hence a fourth name?

1. legacy index  0 -> "nmi"
2. legacy indices 1-8 -> "irq%u" (0-7)
3. legacy indices 9-41 -> "tint%u" (0-31)
4. (not supported) -> "bus-error-int" (or "bus-err"?)

> As the registers to handle the NMI and BUS_ERR_INT are present on the
> IRQC block, the interrupt handler will have to be registered by the
> IRQC block itself by requesting the IRQ. So we will have to skip
> mapping of BUS_ERR_INT as we do for the NMI case. Does that make
> sense?

OK.

BTW, that means RZG2L_NMI from <dt-bindings/interrupt-controller/irqc-rzg2l.h>
will never be used?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [e-mail]

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

Lad, Prabhakar Dec. 19, 2022, 3:09 p.m. UTC | #9

Hi Geert,

On Mon, Dec 19, 2022 at 2:47 PM Geert Uytterhoeven <[e-mail]> wrote:
>
> Hi Prabhakar,
>
> On Mon, Dec 19, 2022 at 3:26 PM Lad, Prabhakar
> <[e-mail]> wrote:
> > On Mon, Dec 19, 2022 at 1:50 PM Geert Uytterhoeven <[e-mail]> wrote:
> > > On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar
> > > <[e-mail]> wrote:
> > > > On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar
> > > > <[e-mail]> wrote:
> > > > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven
> > > > > <[e-mail]> wrote:
> > > > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <[e-mail]> wrote:
> > > > > > > From: Lad Prabhakar <[e-mail]>
> > > > > > >
> > > > > > > Document RZ/G2UL (R9A07G043) IRQC bindings. The RZ/G2UL IRQC block is
> > > > > > > identical to one found on the RZ/G2L SoC. No driver changes are
> > > > > > > required as generic compatible string "renesas,rzg2l-irqc" will be
> > > > > > > used as a fallback.
> > > > > > >
> > > > > > > Signed-off-by: Lad Prabhakar <[e-mail]>
> > >
> > > > > > > Note, renesas,r9a07g043u-irqc is added we have slight difference's compared to RZ/Five
> > > > > > > - G2UL IRQCHIP (hierarchical IRQ domain) -> GIC where as on RZ/Five we have PLIC (chained interrupt
> > > > > > > domain) -> RISCV INTC
> > > > > >
> > > > > > I think this difference is purely a software difference, and abstracted
> > > > > > in DTS through the interrupt hierarchy.
> > > > > > Does it have any impact on the bindings?
> > > > > >
> > > > > > > - On the RZ/Five we have additional registers for IRQC block
> > > > > >
> > > > > > Indeed, the NMI/IRQ/TINT "Interruput" Mask Control Registers, thus
> > > > > > warranting separate compatible values.
> > > > > >
> > > > > > > - On the RZ/Five we have BUS_ERR_INT which needs to be handled by IRQC
> > > > > >
> > > > > > Can you please elaborate? I may have missed something, but to me it
> > > > > > looks like that is exactly the same on RZ/G2UL and on RZ/Five.
> > > > > >
> > > > > Now that we have to update the binding doc with the BUS_ERR_INT too,
> > > > > do you think it would make sense to add interrupt-names too?
> > >
> > > > Gentle ping.
> > >
> > > Thanks for the ping, I had missed you were waiting on input from me.
> > > Sorry for that...
> > >
> > No worries.
> >
> > > As there are three different groups of parent interrupts, adding
> > > interrupt-names makes sense.
> > Ok.
> >
> > > However, as this binding is already in active use since v6.1, you
> > > probably need to keep on supporting the
> > > ack of interrupt-names.  Or do you think there are no real users yet,
> > > and we can drop support for that?
> > >
> > Sorry can you please elaborate on "ack of interrupt-names".
>
> Oops, s/ack/lack/. I.e. what you described below.
>
Got that.

> > So moving forward the driver will first check for interrupt-names
> > property and if that exists it will map the IRQ0-7 and GPIO-TINIT
> > interrupts (based on the names it will create a hierarchy domain) and
> > for the NMI and BUS_ERR_INT we request the IRQ numbers and register
> > the IRQ handler in IRQC driver itself.
> >
> > And for backward compatibility we parse the IRQ numbers based on
> > indexes i.e. 0 = NMI, 1-8  = IRQ 0-7  and 9-41 GPIO TINT interrupts.
>
> Exactly.
>
> > > > > BUS_ERR_INT will have to be handled IRQC itself (i.e. IRQC will
> > > > > register a handler for it).
> > >
> > > Do you mean you will need a fourth parent type for that?
> > >
> > No something like what we have for NMI we can add something similar
> > below for bus error interrupts:
> > interrupts = ....
> >               <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;
> > interrupt-names = ....,
> >              "bus-error-int";
>
> Hence a fourth name?
>
Agreed.

> 1. legacy index  0 -> "nmi"
> 2. legacy indices 1-8 -> "irq%u" (0-7)
> 3. legacy indices 9-41 -> "tint%u" (0-31)
> 4. (not supported) -> "bus-error-int" (or "bus-err"?)
>
"bus-err" I think based on previous experience ;)

While I am at it I'll expand the interrupts property with descriptions.

> > As the registers to handle the NMI and BUS_ERR_INT are present on the
> > IRQC block, the interrupt handler will have to be registered by the
> > IRQC block itself by requesting the IRQ. So we will have to skip
> > mapping of BUS_ERR_INT as we do for the NMI case. Does that make
> > sense?
>
> OK.
>
> BTW, that means RZG2L_NMI from <dt-bindings/interrupt-controller/irqc-rzg2l.h>
> will never be used?
>
Agreed, that needs to be dropped.

Cheers,
Prabhakar

Patch

diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
index 33b90e975e33..8f3678a82ba4 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
@@ -26,6 +26,7 @@  properties:
   compatible:
     items:
       - enum:
+          - renesas,r9a07g043u-irqc   # RZ/G2UL
           - renesas,r9a07g044-irqc    # RZ/G2{L,LC}
           - renesas,r9a07g054-irqc    # RZ/V2L
       - const: renesas,rzg2l-irqc