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]

Date:   Mon, 16 May 2022 08:33:03 +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,

.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,

The  hwirq should match with gpiointN  mentioned in hwmanual. That is all.
Any way it is minor thing, it may be not at all needed. Please ignore this.

Eg:-for gpioint0, it should be

root@...rc-rzg2l:~# cat /proc/interrupts | grep SW
 82:          0          0 11030000.pinctrl 0 Edge      XXX

Not like

root@...rc-rzg2l:~# cat /proc/interrupts | grep SW
 82:          0          0 11030000.pinctrl 120 Edge      XXX

Cheers,
Biju

> 
> >  chip:    GICv3
> >   flags:   0x15
> >              IRQCHIP_SET_TYPE_MASKED
> >              IRQCHIP_MASK_ON_SUSPEND
> >              IRQCHIP_SKIP_SET_WAKE
> >
> > Now coming to current case,
> >
> > Currently GPIO INT 0-122(123 interrupts) corresponding to
> > 120-511(291 interrupts) with same invalid lines.
> >
> > From a debugging point, If user has put same irq name for gpioints(cat
> > /proc/interrupts case), then how do we distinguish these interrupts??
> > (using hwirq??)
> 
> Yes.
> 
> >
> > For using Debugfs, Do we need to first execute cat /proc/interrupts to
> > get virq and from there we need to use virq to get statistics, right?
> 
> It depends what you want to do. /sys/kernel/debug/irq/irqs/ has the exact
> same information. The only thing /proc/interrupts has that debugfs doesn't
> is the per-CPU accounting of delivered interrupts.