linux-kernel - Re: [PATCH] CHROMIUM: arm64: dts: qcom: Add sc7180-gelarshie

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:   Wed, 11 May 2022 10:49:20 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Rob Herring <robh@...nel.org>,
        Julius Werner <jwerner@...omium.org>,
        Krzysztof Kozłowski <k.kozlowski.k@...il.com>,
        Mars Chen <chenxiangrui@...qin.corp-partner.google.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] CHROMIUM: arm64: dts: qcom: Add sc7180-gelarshie

Hi,

On Wed, May 11, 2022 at 10:36 AM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> > * If we want to change our scheme, we'd need to sit down and come to
> > an agreement that satisfies everyone, if such a thing is possible.
>
> There is open CFP for ELCE 2022 (in Ireland). Maybe we could organize
> some session there? But we for sure would need Rob, so the arrangements
> should rather focus on him, not on my availability.

Looks plausible to me to make it.


> > I mean, to be fair I said it _seems_ pure overhead and then said that
> > we could do it if it makes some tools happy. ...but before doing that,
> > I wanted to make sure it was actually valuable. I still have doubts
> > about the assertion that the most specific compatible is guaranteed to
> > uniquely identify hardware. So if the whole reason for doing this is
> > to make the validation tools happy and there's no other value, then at
> > least it's plausible to argue that the tools could simply be fixed to
> > allow this and not shout about it.
>
> Instead of adding bindings, you can indeed change/fix the tools. Go
> ahead. :)

I will try to take a quick look to see what this would look like.


> > Since there no properties associated with the
> > top-level compatible string, it's mostly just checking did some one
> > copy-paste the compatible string from one file (the dts file) to the
> > other file (the yaml file) correctly. To me, that does not feel like a
> > useful check.
>
> Still it can detect messing of SoC compatibles or not defining any
> board-level compatible thus pretending that someone's board is just
> SC7180. Imagine now user-space or bootloader trying to parse it...
>
> BTW, the bindings validation of top-level compatible might actually help
> you - to be sure that DTSes have proper compatibles matching what
> bootloader expects.

I'm still not seeing the help here. Is it somehow going to be easier
for someone to sneak in a dts file to the kernel tree that is just
"sc7180" than it will be to sneak an entry into the bindings that is
just "sc7180"? The people reviewing the dts and the list of allowed
boards in the bindings are the same people, right? Every entry in the
bindings gets used to match exactly one board, so, as I said, it's
pretty much just a question of whether you copy-pasted properly...

-Doug