linux-kernel - Re: [PATCH v3 11/11] arm64: dts: Add Pensando Elba SoC support

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:   Thu, 4 Nov 2021 17:02:04 -0700
From:   Brad Larson <brad@...sando.io>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Mark Rutland <mark.rutland@....com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Arnd Bergmann <arnd@...db.de>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Mark Brown <broonie@...nel.org>,
        Serge Semin <fancer.lancer@...il.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Olof Johansson <olof@...om.net>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-spi <linux-spi@...r.kernel.org>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 11/11] arm64: dts: Add Pensando Elba SoC support

Hi Marc,

On Mon, Oct 25, 2021 at 4:15 AM Marc Zyngier <maz@...nel.org> wrote:
>
> On 2021-10-25 10:17, Mark Rutland wrote:
> > Hi,
> >
> > On Sun, Oct 24, 2021 at 06:51:56PM -0700, Brad Larson wrote:
> >> Add Pensando common and Elba SoC specific device nodes
> >>
> >> Signed-off-by: Brad Larson <brad@...sando.io>
> >
> > [...]
> >> +            gic: interrupt-controller@...000 {
> >> +                    compatible = "arm,gic-v3";
> >> +                    #interrupt-cells = <3>;
> >> +                    #address-cells = <2>;
> >> +                    #size-cells = <2>;
> >> +                    ranges;
> >> +                    interrupt-controller;
> >> +                    reg = <0x0 0x800000 0x0 0x200000>,      /* GICD */
> >> +                          <0x0 0xa00000 0x0 0x200000>;      /* GICR */
>
> This is missing the GICv2 compat regions that the CPUs implement.

Is this what is described as optional in the GIC architecture specification
where a GICv3 system can run restricted GICv2 code?  Can you point
me in the right direction in the spec and example dts node if needed.

> >> +                    interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> >> +
> >> +                    gic_its: msi-controller@...000 {
> >> +                            compatible = "arm,gic-v3-its";
> >> +                            msi-controller;
> >> +                            #msi-cells = <1>;
> >> +                            reg = <0x0 0x820000 0x0 0x10000>;
> >> +                            socionext,synquacer-pre-its =
> >> +                                                    <0xc00000 0x1000000>;
> >> +                    };
> >> +            };
> >
> > Is there any shared lineage with Synquacer? The commit message didn't
> > describe this quirk.
>
> Funny, it looks like there is a sudden outburst of stupid copy/paste
> among HW designers. TI did the exact same thing recently.
>
> This totally negates all the advantages of having an ITS and makes
> sure that you have all the overhead. Facepalm...

Some background may help explain.  To generate an LPI a peripheral must
write to the GITS_TRANSLATER (a specific address). For the ITS to know
which translations apply to the generated interrupts, it must know which
peripheral performed the write. The ID of the peripheral is known as its
DeviceID, which is often carried along with the write as an AXI sideband
signal.

The Elba SoC doesn't carry the DeviceID, so we have to conjure one up
between the peripheral and the ITS.  Instead of telling a peripheral to target
the GITS_TRANSLATER directly, we instead direct it to a specific offset
within a pre-ITS address range (our own IP block).  For writes that land in
that memory range, we derive the DeviceID from (offset >> 2).  The pre-ITS
block then sends (DeviceID, data) to the GITS_TRANSLATER.

The hardware designer came up with the Pre-ITS mechanism in Feb 2018.
When we looked at the upstream kernel later (we developed on 4.14)
we found that not only did it support something similar, it supported the
exact scheme we are using.

Thanks,
Brad