linux-kernel - Re: [PATCH v4 1/3] dt-bindings: interconnect: Add rpmh virt devices

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:   Thu, 24 Nov 2022 11:30:02 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Melody Olvera <quic_molvera@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Georgi Djakov <djakov@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
Cc:     Odelu Kukatla <quic_okukatla@...cinc.com>,
        linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/3] dt-bindings: interconnect: Add rpmh virt devices

On 22/11/2022 18:57, Melody Olvera wrote:
>>>>> +
>>>>> +maintainers:
>>>>> +  - Georgi Djakov <georgi.djakov@...aro.org>
>>>>> +  - Odelu Kukatla <quic_okukatla@...cinc.com>
>>>>> +
>>>>> +description: |
>>>>> +   RPMh interconnect providers support system bandwidth requirements through
>>>>> +   RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
>>>>> +   able to communicate with the BCM through the Resource State Coordinator (RSC)
>>>>> +   associated with each execution environment. Provider nodes must point to at
>>>>> +   least one RPMh device child node pertaining to their RSC and each provider
>>>>> +   can map to multiple RPMh resources. Virtual interconnect providers are not
>>>>> +   controlled by AP and do not support QoS; they should not have associated
>>>>> +   register regions.
>>>>> +
>>>>> +allOf:
>>>>> +  - $ref: qcom,rpmh-common.yaml#
>>>>> +
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    enum:
>>>>> +      - qcom,qdu1000-clk-virt
>>>>> +      - qcom,qdu1000-mc-virt
>>>>> +      - qcom,sm8450-clk-virt
>>>>> +      - qcom,sm8450-mc-virt
>>>> You should also move qcom,sdx65-mc-virt, qcom,sc8280xp-mc-virt,
>>>> qcom,sc8280xp-clk-virt and more.
>>> Ok. I wasn't sure since some of these entries don't seem to conform to
>>> these bindings, even though it seems they should.
>> I have impression that devices I listed conform to these bindings, this
>> is why I listed them. But if you are sure that they do not, then they
>> should not be moved.
> 
> You're correct; those you listed do conform to the new bindings and should be moved.
> I also caught qcom,sc7280-clk-virt which needs to be moved. I'll add to the new bindings.

Actually let's wait a bit with this. For SM8550 we had an idea to move
interconnect to their own bindings file, because they will grow a bit
with allOf:if:then clauses.

Maybe SM8450 and QDU1000 should also go to their own files which will
describe all their interconnects (the virt and the ones requiring clocks)?

Apologies for bringing it late for your patches, but SM8550 is also
happening right now, so new things pop-up :)

Best regards,
Krzysztof