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: <63b76cc7-4a86-fb78-282e-acb16d09bb36@linaro.org>
Date:   Sat, 7 May 2022 19:11:33 +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 07/05/2022 19:04, Krzysztof Kozlowski wrote:
> 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.

This should be:
If they are not identical or you need to assume there will be difference
(for future), then just go with rev4 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


Best regards,
Krzysztof