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]

Message-ID: <ce2ea308-b63d-ad27-4cea-7353268f8ebb@linaro.org>
Date:   Sat, 7 May 2022 19:04:14 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     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>,
        Julius Werner <jwerner@...omium.org>
Subject: Re: [PATCH] CHROMIUM: arm64: dts: qcom: Add sc7180-gelarshie

On 06/05/2022 23:33, Doug Anderson wrote:
> Hi,
> 
> On Wed, May 4, 2022 at 12:04 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@...aro.org> wrote:
>>
>>>>>> The most specific compatible identifies or, like recently Rob confirmed
>>>>>> in case of Renesas, the list of compatibles:
>>>>>> https://lore.kernel.org/linux-devicetree/Yk2%2F0Jf151gLuCGz@robh.at.kernel.org/
>>>>>
>>>>> I'm confused. If the device tree contains the compatibles:
>>>>>
>>>>> "google,lazor-rev4", "google,lazor-rev3", "google,lazor", "qualcomm,sc7180"
>>>>>
>>>>> You want to know what board you're on and you look at the compatible,
>>>>> right? You'll decide that you're on a "google,lazor-rev4" which is the
>>>>> most specific compatible. ...but you could have booted a
>>>>> "google,lazor-rev3". How do you know?
>>>>
>>>> Applying the wrong DTB on the wrong device will always give you the
>>>> wrong answer. You can try too boot google,lazor-rev3 on x86 PC and it
>>>> does not make it a google,lazor-rev3...
>>>
>>> I don't understand what you're saying here. If a device tree has the compatible:
>>>
>>> "google,lazor-rev4", "google,lazor-rev3", "google,lazor", "qualcomm,sc7180"
>>>
>>> You wouldn't expect to boot it on an x86 PC, but you would expect to
>>> boot it on either a "google,lazor-rev4" _or_ a "google,lazor-rev3".
>>
>> Yes, but booting it does not mean that the hardware is rev3 or rev4.
>> Booting it means only that we are running DTB on a compatible hardware.
>> The DTB determines what is accessible to user-space, not what *really*
>> the hardware is. The user-space (since we are going now to original
>> question) reads it and can understand that it is running on hardware
>> compatible with rev3 - either rev3 or rev4 - and act accordingly.
>>
>>> Correct? Now, after we've booted software wants to look at the
>>> compatible of the device tree that was booted. The most specific entry
>>> in that device tree is "google,lazor-rev4". ...but we could have
>>> booted it on a "google,lazor-rev3". How can you know?
>>
>> No, providing and loading a rev4 DTB on a rev3 board is not correct and
>> does not make any sense. rev3 boards are not compatible with rev4, it's
>> the other way. Not every fruit is an apple, but every apple is a fruit.
>> This is why I used that example - if you load rev4 DTB on rev3 hardware
>> then you have totally wrong booting process.
> 
> I think this is the crux of the difference in opinion and there's no
> reasonable way I'm aware of to do what you're asking. If -rev3 and
> -rev4 are identical from a software point of view it would be silly
> not to share a device tree for the two of them. The number of device
> trees we'd have to land in the kernel tree would be multiplied by
> several times and we'd have many that are identical except for this
> compatible string. I see no benefit here and lots of downside.

Wait, we agreed that you don't consider them identical, didn't we? If
they are identical, you do not need rev4 at all. So they are not
identical...

If they are identical, just use rev3 and problem is gone.
If they are not identical or you need to assume there will be difference
(for future), then just go with rev3 without fallback to rev3 and also
problem is gone.

Right now it's not possible to validate QCOM DTSes against DT bindings
because they throw big fat warnings about undocumented top compatibles.
This is a downside for us.

Remember, you do not have to use Devicetree or Linux at all if it causes
you some downsides... No one is forced. :) If you choose to use it,
sorry, it comes with some requirements like being following Devicetree
specification or the binding guidelines.

Best regards,
Krzysztof