| 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
| ||
|
Message-ID: <87y24y112a.wl-maz@kernel.org>
Date: Mon, 06 Dec 2021 10:26:37 +0000
From: Marc Zyngier <maz@...nel.org>
To: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
Cc: Rob Herring <robh@...nel.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"kernel-team@...roid.com" <kernel-team@...roid.com>,
John Crispin <john@...ozen.org>, Biwen Li <biwen.li@....com>,
Chris Brandt <Chris.Brandt@...esas.com>,
"linux-renesas-soc@...r.kernel.org"
<linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH] of/irq: Add a quirk for controllers with their own definition of interrupt-map
On Sun, 05 Dec 2021 22:27:35 +0000,
"Lad, Prabhakar" <prabhakar.csengg@...il.com> wrote:
>
> On Wed, Dec 1, 2021 at 4:16 PM Lad, Prabhakar
> <prabhakar.csengg@...il.com> wrote:
> >
> > On Wed, Dec 1, 2021 at 2:36 PM Rob Herring <robh@...nel.org> wrote:
> > >
> > > On Wed, Dec 1, 2021 at 7:37 AM Lad, Prabhakar
> > > <prabhakar.csengg@...il.com> wrote:
> > > >
> > > > Hi Marc/Rob,
> > > >
> > > > On Tue, Nov 30, 2021 at 6:37 PM Marc Zyngier <maz@...nel.org> wrote:
> > > > >
> > > > > On Tue, 30 Nov 2021 12:52:21 +0000,
> > > > > "Lad, Prabhakar" <prabhakar.csengg@...il.com> wrote:
> > > > > >
> > > > > > On Mon, Nov 29, 2021 at 6:33 PM Rob Herring <robh@...nel.org> wrote:
> > > > > > >
> > > > > > > interrupts would work just fine here:
> > > > > > >
> > > > > > > interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
> > > > > > > <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
> > > > > > >
> > > > > > > We don't need a different solution for N:1 interrupts from N:M. Sure,
> > > > > > > that could become unweldy if there are a lot of interrupts (just like
> > > > > > > interrupt-map), but is that an immediate problem?
> > > > > > >
> > > > > > It's just that with this approach the driver will have to index the
> > > > > > interrupts instead of reading from DT.
> > > > > >
> > > > > > Marc - is it OK with the above approach?
> > > > >
> > > > > Anything that uses standard properties in a standard way works for me.
> > > > >
> > > > I added interrupts property now instead of interrupt-map as below:
> > > >
> > > > irqc: interrupt-controller@...a0000 {
> > > > compatible = "renesas,r9a07g044-irqc", "renesas,rzg2l-irqc";
> > > > #address-cells = <0>;
> > > > interrupt-parent = <&gic>;
> > > > interrupt-controller;
> > > > reg = <0 0x110a0000 0 0x10000>;
> > > > interrupts =
> > > > <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 445 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 447 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 450 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 451 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 452 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 453 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 454 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 455 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 457 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 459 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 460 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 461 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 470 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 472 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 473 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 474 IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 475 IRQ_TYPE_LEVEL_HIGH>;
> > > > clocks = <&cpg CPG_MOD R9A07G044_IA55_CLK>,
> > > > <&cpg CPG_MOD R9A07G044_IA55_PCLK>;
> > > > clock-names = "clk", "pclk";
> > > > power-domains = <&cpg>;
> > > > resets = <&cpg R9A07G044_IA55_RESETN>;
> > > > };
> > > >
> > > >
> > > > In the hierarchal interrupt code its parsed as below:
> > > > on probe fetch the details:
> > > > range = of_get_property(np, "interrupts", &len);
> > > > if (!range)
> > > > return -EINVAL;
> > > >
> > > > for (len /= sizeof(*range), j = 0; len >= 3; len -= 3) {
> > > > if (j >= IRQC_NUM_IRQ)
> > > > return -EINVAL;
> > > >
> > > > priv->map[j].args[0] = be32_to_cpu(*range++);
> > > > priv->map[j].args[1] = be32_to_cpu(*range++);
> > > > priv->map[j].args[2] = be32_to_cpu(*range++);
> > > > priv->map[j].args_count = 3;
> > > > j++;
> > >
> > > Not sure what's wrong, but you shouldn't be doing your own parsing.
> > > The setup shouldn't look much different than a GPIO controller
> > > interrupts except you have multiple parent interrupts.
> > >
> > Sorry does that mean the IRQ domain should be chained handler and not
> > hierarchical? Or is it I have miss-understood.
I guess the core DT code allocates the interrupts itself, as if the
interrupt controller was the interrupt producer itself (which isn't
the case here), bypassing the hierarchical setup altogether.
We solved it on the MSI side by not using 'interrupts'. Either we
adopt a similar solution for wired interrupts, or we fix the core DT
code.
> >
> > If the IRQ domain has to be hierarchical how do we map to the parent?
> > (based on the previous reviews Marc had suggested to implement as
> > hierarchical [1])
> >
> Gentle ping.
Please move this discussion to the relevant thread.
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists