linux-kernel - Re: [PATCH 1/2] dt-bindings: arm: qcom: document zoglin board

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]

Message-ID: <CAD=FV=XPTUVKMSrcZdaoztrMU9pCJWXkHLfW-1dHqG70-iR3Yw@mail.gmail.com>
Date:   Wed, 27 Jul 2022 14:58:25 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Rob Herring <robh@...nel.org>
Cc:     Bob Moragues <moragues@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Bob Moragues <moragues@...gle.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: arm: qcom: document zoglin board

Hi,

On Wed, Jul 27, 2022 at 12:43 PM Rob Herring <robh@...nel.org> wrote:
>
> On Wed, Jul 27, 2022 at 11:40 AM Doug Anderson <dianders@...omium.org> wrote:
> >
> > Hi,
> >
> > On Wed, Jul 27, 2022 at 9:03 AM Rob Herring <robh@...nel.org> wrote:
> > >
> > > On Tue, Jul 26, 2022 at 09:24:31PM -0700, Bob Moragues wrote:
> > > > Zoglin is a Hoglin Chromebook with SPI Flash reduced from 64MB to 8MB.
> > > > Zoglin is identical to Hoglin except for the SPI Flash.
> > > > The actual SPI Flash is dynamically probed at and not specified in DTS.
> > > >
> > > > Signed-off-by: Bob Moragues <moragues@...omium.org>
> > > >
> > > > Signed-off-by: Bob Moragues <moragues@...gle.com>
> > > > ---
> > > >
> > > >  Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> > > > index 581485392404..63091df3cbb3 100644
> > > > --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> > > > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> > > > @@ -475,6 +475,7 @@ properties:
> > > >
> > > >        - description: Qualcomm Technologies, Inc. sc7280 CRD platform (newest rev)
> > > >          items:
> > > > +          - const: google,zoglin
> > > >            - const: google,hoglin
> > > >            - const: qcom,sc7280
> > >
> > > Is just "google,hoglin", "qcom,sc7280" no longer valid? If it is valid,
> > > you need another entry.
> >
> > If it makes people happy to have another entry then it wouldn't hurt,
> > but it has no long term benefit and I would recommend against it. The
> > next patch in this series changes the existing "hoglin" device tree to
> > have all 3 compatible strings and thus when both patches land then
> > make dtbs_check will pass. I assume that is the only goal of
> > documenting these boards here. Certainly if you had a device tree that
> > had only "google,zoglin" it would boot fine on zoglin devices and if
> > you had a device tree that had only "google,hoglin" it would boot fine
> > on hoglin device. This is true of all of the entries for Chromebooks
> > that have multiple compatible entries.
>
> Why even add the entry? If it is just a different SPI flash, you can
> tell that from the SPI flash compatible or device ID.

Yeah, it's really unfortunate. :( The issue is a limitation in the
ChromeOS bootloader infrastructure. The ChromeOS build infrastructure
cannot handle something that it considers the same "board" as having
different SPI flash sizes. This is because the infrastructure always
requires that the bootloader "image" be the exact same size as the SPI
flash and it assumes a universal firmware (single image) per board.
It's unfortunately not very flexible but normally for a given board
the SPI flash size is chosen at the start and never changed. The CRD
board was an exception here. Though it's not beautiful, this means
that the firmware considers this as a different board and looks for a
different compatible string on the kernel command line.

-Doug