linux-kernel - RE: [PATCH v3 5/5] pinctrl: renesas: pinctrl-rzg2l: Add IRQ domain to handle GPIO interrupt

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>] [day] [month] [year] [list]

Message-ID: <OS0PR01MB5922E1334896347568BA2E7A86CF9@OS0PR01MB5922.jpnprd01.prod.outlook.com>
Date:   Mon, 16 May 2022 09:56:33 +0000
From:   Biju Das <biju.das.jz@...renesas.com>
To:     Marc Zyngier <maz@...nel.org>
CC:     "Lad, Prabhakar" <prabhakar.csengg@...il.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Phil Edworthy <phil.edworthy@...esas.com>
Subject: RE: [PATCH v3 5/5] pinctrl: renesas: pinctrl-rzg2l: Add IRQ domain to
 handle GPIO interrupt

Hi Marc,

> Subject: Re: [PATCH v3 5/5] pinctrl: renesas: pinctrl-rzg2l: Add IRQ
> domain to handle GPIO interrupt
> 
> On Mon, 16 May 2022 09:33:03 +0100,
> Biju Das <biju.das.jz@...renesas.com> wrote:
> >
> > Hi Marc,
> >
> > .org>; Phil Edworthy
> > > <phil.edworthy@...esas.com>
> > > Subject: Re: [PATCH v3 5/5] pinctrl: renesas: pinctrl-rzg2l: Add IRQ
> > > domain to handle GPIO interrupt
> > >
> > > On Mon, 16 May 2022 08:20:47 +0100,
> > > Biju Das <biju.das.jz@...renesas.com> wrote:
> > > >
> > > > > >
> > > > > > I believe from interrupt statistics point of view, cat
> > > > > > /proc/interrupts should report actual gpioint number (0->122)
> > > > > > corresponding to pin index for SW1, SW2 and SW3 ??
> > > > >
> > > > > No. There is no need for such userspace-visible behaviour.
> > > > > Userspace has no business tracking those. The required
> > > > > information is in debugfs, and that more than enough.
> > > >
> > > > Ok, So far I used cat /proc/interrupts for debugging, since I
> > > > don't need to enable DEBUG config for Enabling Debugfs for irq.
> > > > This Debugfs irq is new info to me.
> > > >
> > > > Our hardware manual has below info for usb-phy irq
> > > > 2H0_OBINT	126(InterruptID)	SPI 94	IRQ 94	Level
> > > >
> > > > cat /proc/interrupts matches with GICV3 Interrupt ID/ type in the
> > > > HW
> > > manual
> > > > 113:          0          0     GICv3 126 Level     11c50200.usb-phy
> > > >
> > > > Debugfs is also showing similar info like hwirq and interrupt type.
> > > > But I don't know which field corresponds to number of interrupts?
> > > >
> > > > root@...rc-rzg2l:~# cat /sys/kernel/debug/irq/irqs/113
> > > > handler:  handle_fasteoi_irq
> > > > device:   (null)
> > > > status:   0x00000104
> > > > istate:   0x00000000
> > > > ddepth:   0
> > > > wdepth:   0
> > > > dstate:   0x13402204
> > > >             IRQ_TYPE_LEVEL_HIGH
> > > >             IRQD_LEVEL
> > > >             IRQD_ACTIVATED
> > > >             IRQD_IRQ_STARTED
> > > >             IRQD_SINGLE_TARGET
> > > >             IRQD_DEFAULT_TRIGGER_SET
> > > >             IRQD_HANDLE_ENFORCE_IRQCTX
> > > > node:     0
> > > > affinity: 0-1
> > > > effectiv: 0
> > > > domain:  :soc:interrupt-controller@...00000-1
> > > >  hwirq:   0x7e
> > >
> > > 0x7e = 126 = 94 - 32 -> SPI94.
> > >
> > > What else do you need?
> >
> > OK, similar to GIC, I thought for gpio interrupts,
> 
> Err. This *IS* the GIC.

Yes, tint0-31(IA55 driver) is connected to the GIC which is backend
On the frontend(Pincontrol driver) where we have 123 interrupts (gpioint0-122) is mapped to tint0_31.
So parent of a particular gpio interrupt can be changed during insmod/rmmod operation.

> 
> > The  hwirq should match with gpiointN  mentioned in hwmanual. That is
> all.
> 
> There is no such need.
> 
> hwirq is whatever the driver decides it is, and userspace can't rely on it
> one way or another. If the driver author decides that it is more
> convenient to number hwirqs backwards, that's absolutely fine. If you are
> debugging, you have access to the driver code, the DT, and all the debugfs
> information. You can trace things back and forth as you please.

OK agreed.

Regards,
Biju