linux-kernel - Re: [PATCH v2 1/4] dt-bindings: firmware: scm: Add QDU1000/QRU1000 compatibles

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: <a8d38406-6294-581a-9677-ff2e686eca50@linaro.org>
Date:   Thu, 20 Oct 2022 08:35:42 -0400
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Melody Olvera <quic_molvera@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
Cc:     Robert Marko <robimarko@...il.com>,
        Guru Das Srinagesh <quic_gurus@...cinc.com>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/4] dt-bindings: firmware: scm: Add QDU1000/QRU1000
 compatibles

On 19/10/2022 14:08, Melody Olvera wrote:
> 
> 
> On 10/15/2022 6:34 AM, Krzysztof Kozlowski wrote:
>> On 14/10/2022 18:11, Melody Olvera wrote:
>>> Add compatibles for scm driver for QDU1000 and QRU1000 platforms.
>>>
>>> Signed-off-by: Melody Olvera <quic_molvera@...cinc.com>
>>> ---
>>>  .../devicetree/bindings/firmware/qcom,scm.yaml   | 16 ++++++++++++++++
>>>  1 file changed, 16 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>> index c5b76c9f7ad0..47083f47f109 100644
>>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
>>> @@ -38,6 +38,8 @@ properties:
>>>            - qcom,scm-msm8994
>>>            - qcom,scm-msm8996
>>>            - qcom,scm-msm8998
>>> +          - qcom,scm-qdu1000
>>> +          - qcom,scm-qru1000
>> Why exactly we are no using qdu1000 as fallback? That was the
>> recommendation in previous discussion.
> Will use only qdu; I think I misunderstood the outcome of that discussion.

Actually, I think I commented about this in wrong patch. I think the
outcome was to use two compatibles for most of the cases, but as a
fallback, so:

QDU: "qcom,qdu1000-rpmhpd"
QRU: "qcom,qru1000-rpmhpd", "qcom,qdu1000-rpmhpd"
(or skip entirely second if you do not customize QRU in DTSI)

However here we already have a fallback, so these are fine:

"qcom,scm-qdu1000", "qcom,scm"
"qcom,scm-qru1000", "qcom,scm"

Still assuming you customize them in DTSI... which does not seem the
case, right?

>>
>> Patch is still incomplete - you still do no have proper changes in allOf
>> for the clocks. If you want to say that this SoC does not take any
>> clocks as input, then they should not be allowed.
> That is what I'm trying to say; it seems most of our most recent SoCs (sm8*) don't have any
> clocks associated with the scm. Does it make sense to remove the minItems earlier
> in the binding, or is there something else that would communicate this in allOf better?
> 


Then disallow clocks for your variant:

  - if:
     ....
    then:
     ...
      clocks: false
      clock-names: false

Best regards,
Krzysztof