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

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] [day] [month] [year] [list]
Message-ID: <CA+V-a8sGe83hWRb228YPLy7_9Ap7N4abP36hj_y+Ms7zuj+wfw@mail.gmail.com>
Date:   Mon, 19 Dec 2022 15:09:04 +0000
From:   "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Magnus Damm <magnus.damm@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-gpio@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Biju Das <biju.das.jz@...renesas.com>,
        Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH RFC 1/5] dt-bindings: interrupt-controller:
 renesas,rzg2l-irqc: Document RZ/G2UL SoC

Hi Geert,

On Mon, Dec 19, 2022 at 2:47 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Mon, Dec 19, 2022 at 3:26 PM Lad, Prabhakar
> <prabhakar.csengg@...il.com> wrote:
> > On Mon, Dec 19, 2022 at 1:50 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > On Mon, Dec 19, 2022 at 1:57 PM Lad, Prabhakar
> > > <prabhakar.csengg@...il.com> wrote:
> > > > On Fri, Nov 18, 2022 at 12:29 PM Lad, Prabhakar
> > > > <prabhakar.csengg@...il.com> wrote:
> > > > > On Thu, Nov 17, 2022 at 10:54 AM Geert Uytterhoeven
> > > > > <geert@...ux-m68k.org> wrote:
> > > > > > On Mon, Nov 7, 2022 at 6:53 PM Prabhakar <prabhakar.csengg@...il.com> wrote:
> > > > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > > > > > >
> > > > > > > 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 <prabhakar.mahadev-lad.rj@...renesas.com>
> > >
> > > > > > > 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