linux-kernel - Re: [PATCH] dt-bindings: firmware: document Qualcomm SM6375 SCM

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: <90185f20-f91a-54b9-bb46-d186419b5169@linaro.org>
Date:   Tue, 27 Sep 2022 13:42:00 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Guru Das Srinagesh <quic_gurus@...cinc.com>
Cc:     Konrad Dybcio <konrad.dybcio@...ainline.org>,
        ~postmarketos/upstreaming@...ts.sr.ht, martin.botka@...ainline.org,
        angelogioacchino.delregno@...ainline.org,
        marijn.suijten@...ainline.org, jamipkettunen@...ainline.org,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Robert Marko <robimarko@...il.com>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: firmware: document Qualcomm SM6375 SCM

On 26/09/2022 18:59, Guru Das Srinagesh wrote:
> On Sep 24 2022 10:17, Krzysztof Kozlowski wrote:
>> On 24/09/2022 02:09, Guru Das Srinagesh wrote:
>>> On Sep 21 2022 20:43, Konrad Dybcio wrote:
>>>> Does it? I did not define this compatible in the driver, so it does
>>>> not consume any clocks.
>>>
>>> The bindings should describe only those compatibles that the driver supports -
>>> that is, both the driver and its bindings should be in sync.
>>
>> That's not entirely true. Bindings describe the hardware in the most
>> complete way we can. Not the driver. Whether driver supports something
>> or not, is not relevant here, except that we don't want to document
>> non-existing things or stuff out of tree.
> 
> Is this only applicable to compatibles or device tree properties in general?

This applies to everything.

> 
>>>
>>> Could you please update the driver with this compatible as well? Let's not
>>> merge this change without that first.
>>
>> This could be even merged without change in the driver. However it's not
>> the case here as driver already supports it, so your request is fulfilled.
> 
> My concern is that if somebody specifies a compatible/device tree property that
> the driver doesn't support, their expectations from adding that change will not
> be met. In addition to having the bindings describe HW in full, I think the
> driver should also be in sync with it for this reason.

As Rob answered, it might be difficult to keep all drivers in all
operating systems, bootloaders and firmware components to be in sync. :)

Best regards,
Krzysztof