linux-kernel - Re: [PATCH] of/irq: Add a quirk for controllers with their own definition of interrupt-map

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

Date:   Tue, 23 Nov 2021 09:11:11 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        kernel-team@...roid.com, Rob Herring <robh@...nel.org>,
        John Crispin <john@...ozen.org>, Biwen Li <biwen.li@....com>,
        Chris Brandt <chris.brandt@...esas.com>,
        linux-renesas-soc@...r.kernel.org,
        Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH] of/irq: Add a quirk for controllers with their own definition of interrupt-map

On Tue, 23 Nov 2021 08:44:19 +0000,
Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> 
> Hi Marc,
> 
> On Tue, Nov 23, 2021 at 9:33 AM Marc Zyngier <maz@...nel.org> wrote:
> > On Tue, 23 Nov 2021 07:57:48 +0000,
> > Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > Summarized:
> > >   - Before the bad commit, and after your fix, irqc-rza1 is invoked,
> > >     and the number of interrupts seen is correct, but input events
> > >     are doubled.
> > >   - After the bad commit, irqc-rza1 is not invoked, and there is an
> > >     interrupt storm, but input events are OK.
> >
> > OK, that's reassuring, even if the "twice the events" stuff isn't what
> > you'd expect. We at least know this is a separate issue, and that this
> > patch on top of -rc1 brings you back to the 5.15 behaviour.
> >
> > I'd expect it to be the case for the other platforms as well.
> 
> OK.
> 
> BTW, what would have been the correct way to do this for irqc-rza1?
> I think we're about to make the same mistake with RZ/G2L IRQC
> support[1]?

Indeed, and I was about to look into it.

There are multiple ways to skin this cat, including renaming
'interrupt-map' to 'my-own-private-interrupt-map'. Or use something
akin the new 'msi-range' (which we could call interrupt-range), and
replace:

  interrupt-map = <0 0 &gic GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
                  <1 0 &gic GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
                  <2 0 &gic GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
                  <3 0 &gic GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
                  <4 0 &gic GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
                  <5 0 &gic GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
                  <6 0 &gic GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
                  <7 0 &gic GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;

with:

  interrupt-range = <&gic GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH 0 8>;

which reads as "base interrupt spec", "start pin", "count".  This
gives you almost the same level of information, and doesn't interfere
with the rest of the DT properties. Parsing it is also much simpler.
But that's up to you, really.

	M.

-- 
Without deviation from the norm, progress is not possible.