Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230511150539.6.Ia0b6ebbaa351e3cd67e201355b9ae67783c7d718@changeid>
 <20230511150539.3.I525a2ed4260046d43c885ee1275e91707743df1c@changeid> <86ttwim0h9.wl-maz@kernel.org>
In-Reply-To: <86ttwim0h9.wl-maz@kernel.org>
From:   Doug Anderson <dianders@chromium.org>
Date:   Fri, 12 May 2023 07:15:21 -0700
Message-ID: <CAD=FV=U63oWO+jSdSPN9ruRyyaFKQOMPOGHwio5+6j4vvygS-Q@mail.gmail.com>
Subject: Re: [PATCH 3/6] arm64: dts: mediatek: mt8183: Add mediatek,gicr-save-quirk
To:     Marc Zyngier <maz@kernel.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        devicetree@vger.kernel.org, linux-mediatek@lists.infradead.org,
        wenst@chromium.org, Eddie Huang <eddie.huang@mediatek.com>,
        Allen-KH Cheng <allen-kh.cheng@mediatek.com>,
        Ben Ho <Ben.Ho@mediatek.com>, Weiyi Lu <weiyi.lu@mediatek.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>,
        linux-arm-kernel@lists.infradead.org,
        Tinghan Shen <tinghan.shen@mediatek.com>, jwerner@chromium.org,
        Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>,
        yidilin@chromium.org, Seiya Wang <seiya.wang@mediatek.com>,
        Conor Dooley <conor+dt@kernel.org>,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi,

On Fri, May 12, 2023 at 1:13=E2=80=AFAM Marc Zyngier <maz@kernel.org> wrote=
:
>
> On Thu, 11 May 2023 23:05:37 +0100,
> Douglas Anderson <dianders@chromium.org> wrote:
> >
> > Firmware shipped on mt8183 Chromebooks is affected by the GICR
> > save/restore issue as described by the patch ("dt-bindings:
> > interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/
> > broken FW"). Add the quirk property.
> >
> > Fixes: e526c9bc11f8 ("arm64: dts: Add Mediatek SoC MT8183 and evaluatio=
n board dts and Makefile")
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> >  arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot=
/dts/mediatek/mt8183.dtsi
> > index 5169779d01df..39545172fce5 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > @@ -709,6 +709,7 @@ gic: interrupt-controller@c000000 {
> >                             <0 0x0c400000 0 0x2000>,   /* GICC */
> >                             <0 0x0c410000 0 0x1000>,   /* GICH */
> >                             <0 0x0c420000 0 0x2000>;   /* GICV */
> > +                     mediatek,gicr-save-quirk;
>
> Is that something you can safely generalise at the SoC level? Are
> these SoC solely used on Chromebooks, and/or

Hmmm, I thought I checked to make sure that the only users of these
upstream were Chromebooks, but I just double-checked and I obviously
was blind yesterday. You're right that I need to fix this. I will move
these to:

mt8195-cherry.dtsi
mt8192-asurada.dtsi
mt8183-kukui.dtsi

...it looks as if the common "baseboard" dtsi for mt8186 Chromebooks
hasn't been upstreamed yet, so we'll have to keep an eye on that and
make sure it gets the property.

When I spin this series early next week I'll make that change.


> without any hope of
> seeing any alternative FW being already in use?

I haven't seen anyone try to fully replace the firmware of a
Chromebook in the past. It would be a lot of work, certainly. More
common, I'd think, would be someone chaining an extra level of loader
between the existing firmware and the OS. I _think_ I've seen people
use a stripped down U-Boot for this. However, the "resident" firmware
would still be the one that the Chromebook ships with.

Certainly someone could prove me wrong and re-implement the firmware
on one of these Chromebooks. That person would need to follow the same
convention or accept that their kernel won't be enabling pseudoNMIs.

-Doug