Re: [PATCH v2 4/6] irqchip/renesas-rzv2h: Make IRQ type handling range-aware

From: Lad, Prabhakar

Date: Wed Feb 04 2026 - 05:57:25 EST


Hi Biju,

On Wed, Feb 4, 2026 at 10:41 AM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
>
> Hi Prabhakar,
>
> > -----Original Message-----
> > From: Lad, Prabhakar <prabhakar.csengg@xxxxxxxxx>
> > Sent: 04 February 2026 10:32
> > Subject: Re: [PATCH v2 4/6] irqchip/renesas-rzv2h: Make IRQ type handling range-aware
> >
> > On Wed, Feb 4, 2026 at 10:25 AM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
> > >
> > > > -----Original Message-----
> > > > From: Lad, Prabhakar <prabhakar.csengg@xxxxxxxxx>
> > > > Sent: 04 February 2026 10:20
> > > > To: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> > > > Cc: Thomas Gleixner <tglx@xxxxxxxxxx>; Philipp Zabel
> > > > <p.zabel@xxxxxxxxxxxxxx>; Geert Uytterhoeven
> > > > <geert+renesas@xxxxxxxxx>; magnus.damm <magnus.damm@xxxxxxxxx>;
> > > > linux-kernel@xxxxxxxxxxxxxxx; linux- renesas-soc@xxxxxxxxxxxxxxx;
> > > > Fabrizio Castro <fabrizio.castro.jz@xxxxxxxxxxx>; Prabhakar Mahadev
> > > > Lad <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> > > > Subject: Re: [PATCH v2 4/6] irqchip/renesas-rzv2h: Make IRQ type
> > > > handling range-aware
> > > >
> > > > Hi Biju,
> > > >
> > > > On Wed, Feb 4, 2026 at 6:52 AM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
> > > > >
> > > > > Hi Prabhakar,
> > > > >
> > > > > Thanks for the patch.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Prabhakar <prabhakar.csengg@xxxxxxxxx>
> > > > > > Sent: 03 February 2026 23:18
> > > > > > Subject: [PATCH v2 4/6] irqchip/renesas-rzv2h: Make IRQ type
> > > > > > handling range-aware
> > > > > >
> > > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> > > > > >
> > > > > > Refine IRQ type handling to explicitly bound IRQ and TINT ranges
> > > > > > and dispatch based on the hardware IRQ number.
> > > > > >
> > > > > > This restructures the logic to clearly separate NMI, IRQ, and
> > > > > > TINT handling and ensures out-of-range interrupts are ignored
> > > > > > safely. The change prepares the driver for adding CA55
> > > > > > interrupts into the IRQ hierarchy domain by making the
> > > > interrupt classification explicit and extensible.
> > > > > >
> > > > > > Signed-off-by: Lad Prabhakar
> > > > > > <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> > > > > > ---
> > > > > > v1->v2:
> > > > > > - New patch.
> > > > > > ---
> > <snip>
> > > > > >
> > > > > > if (ret)
> > > > > > return ret;
> > > > > > @@ -507,11 +528,11 @@ static int rzv2h_icu_alloc(struct
> > > > > > irq_domain *domain, unsigned int virq,
> > > > unsigne
> > > > > > * fwspec->param[0].
> > > > > > * hwirq is embedded in bits 0-15.
> > > > > > * TINT is embedded in bits 16-31.
> > > > > > + * Check if bits 16-31 are set to identify TINT interrupts.
> > > > > > */
> > > > > > - if (hwirq >= ICU_TINT_START) {
> > > > > > - tint = ICU_TINT_EXTRACT_GPIOINT(hwirq);
> > > > > > + tint = ICU_TINT_EXTRACT_GPIOINT(hwirq);
> > > > > > + if (tint) {
> > > > >
> > > > > Is tint == 0 does not happen?? I mean GPIOint == 0 is invalid??
> > > > >
> > > > For the P0_0 case, tint = 0 and hwirq == ICU_TINT_EXTRACT_HWIRQ(hwirq).
> > > > In this situation, we do not need to enter the if condition.
> > >
> > > You mean, no need to do the belowcheck if tint =0. But do only this check if tint > 0.
> > >
> > No, I meant we didn't need to re-extract hwirq.
> >
> > > if (hwirq < ICU_TINT_START)
> > Ok, to do this check I will update the if check to below so that the above check is done.
> >
> > if (tint || (hwirq >= ICU_TINT_START && hwirq <= ICU_TINT_LAST)) {
>
> But this will skip the hwirq invalid entry?? for eg:- tint=0, hwirq=2
>
Will this case ever happen?

Below is the current code in next [0], which does not handle this case.
/*
* For TINT interrupts the hwirq and TINT are encoded in
* fwspec->param[0].
* hwirq is embedded in bits 0-15.
* TINT is embedded in bits 16-31.
*/
if (hwirq >= ICU_TINT_START) {
tint = ICU_TINT_EXTRACT_GPIOINT(hwirq);
hwirq = ICU_TINT_EXTRACT_HWIRQ(hwirq);

if (hwirq < ICU_TINT_START)
return -EINVAL;
}

Please propose the changes you want me to add if the above mentioned
invalid case ever happens.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/irqchip/irq-renesas-rzv2h.c?h=next-20260203#n505

Cheers,
Prabhakar