linux-kernel - Re: [PATCH 1/3] dt-bindings: arm: qcom: Add sc7180 Chromebook board bindings

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=WNSv+kgTZwjHVq+YNQAG0uB42QUPaU-BPTV_W+j=5aYg@mail.gmail.com>
Date:   Fri, 13 May 2022 10:00:20 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Rob Herring <robh@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Alexandru M Stan <amstan@...omium.org>,
        Rajendra Nayak <quic_rjendra@...cinc.com>,
        "Joseph S . Barrera III" <joebar@...omium.org>,
        Julius Werner <jwerner@...omium.org>,
        Andy Gross <agross@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Rob Herring <robh+dt@...nel.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>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] dt-bindings: arm: qcom: Add sc7180 Chromebook board bindings

Hi,

On Fri, May 13, 2022 at 2:01 AM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> On 13/05/2022 09:57, Krzysztof Kozlowski wrote:
> > On 12/05/2022 18:04, Douglas Anderson wrote:
> >> This copy-pastes compatibles from sc7180-based boards from the device
> >> trees to the yaml file so that `make dtbs_check` will be happy.
> >>
> >> NOTES:
> >> - I make no attempt to try to share an "item" for all sc7180 based
> >>   Chromebooks. Because of the revision matching scheme used by the
> >>   Chromebook bootloader, at times we need a different number of
> >>   revisions listed.
> >> - Some of the odd entries in here (like google,homestar-rev23 or the
> >>   fact that "Google Lazor Limozeen without Touchscreen" changed from
> >>   sku5 to sku6) are not typos but simply reflect reality.
> >> - Many revisions of boards here never actually went to consumers, but
> >>   they are still in use within various companies that were involved in
> >>   Chromebook development. Since Chromebooks are developed with an
> >>   "upstream first" methodology, having these revisions supported with
> >>   upstream Linux is important. Making it easy for Chromebooks to be
> >>   developed with an "upstream first" methodology is valuable to the
> >>   upstream community because it improves the quality of upstream and
> >>   gets Chromebooks supported with vanilla upstream faster.
> >>
> >> Signed-off-by: Douglas Anderson <dianders@...omium.org>
> >> ---
> >>
> >>  .../devicetree/bindings/arm/qcom.yaml         | 180 ++++++++++++++++++
> >>  1 file changed, 180 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> >> index 5c06d1bfc046..399be67eb5d2 100644
> >> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> >> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> >> @@ -214,11 +214,191 @@ properties:
> >>                - qcom,ipq8074-hk10-c2
> >>            - const: qcom,ipq8074
> >>
> >> +      # Qualcomm Technologies, Inc. SC7180 IDP
> >>        - items:
> >>            - enum:
> >>                - qcom,sc7180-idp
> >>            - const: qcom,sc7180
> >>
> >> +      # Google CoachZ (rev1 - 2)
> >> +      - items:
> >> +          - const: google,coachz-rev1
> >> +          - const: google,coachz-rev2
> >
> > The inverted pattern of old revision being compatible with the new one,
> > is done on purpose? You claim here every rev1 is always compatible with
> > rev2 ...
> >
> > I don't think we discussed such patterns in previous talk. I quickly
> > went through it and there were only skuX moving around, not rev1 being
> > newer then rev2.

Isn't this what we just had a whole discussion about?

Oh, I see. You're objecting to the fact that the order here lists
"rev1" first and "rev2" second.

I think the issue here is that for the purposes of booting Chromebooks
the order here doesn't matter. Certainly we can pick a fixed order and
we can validate that the order in the yaml matches the order in the
device tree, but for all intents and purposes it doesn't matter to
anything. The same device tree is compatible with _both_ rev1 and rev2
coachz devices. Neither of those two devices is inherently better
supported by this device tree than the other.

We can reorder them if it's important for some reason, but it doesn't
change the facts of the matter. You can't tell whether you've booted a
"-rev1" Chromebook or a "-rev2" Chromebook based on the most specific
compatible string.

As per the other discussion, we could "solve" this by making two
device trees that were exactly the same but one of them had the
compatible "-rev1" the other "-rev2". This would result in a big
explosion in the number of device trees in our FIT Image for very
little gain. It also fails to solve the "newest rev" problem.


OK, so I've written up a description of the whole system. Maybe it
will be clearer with that and we can continue the discussion in my v2
if needed.

https://lore.kernel.org/r/20220513095722.v2.1.I71e42c6174f1cec17da3024c9f73ba373263b9b6@changeid

-Doug