linux-kernel - Re: [PATCH v3 4/5] dt-bindings: cpufreq: cpufreq-qcom-hw: Add SDX75 compatible

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:   Fri, 9 Jun 2023 11:17:08 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Pavan Kondeti <quic_pkondeti@...cinc.com>,
        Rohit Agarwal <quic_rohiagar@...cinc.com>
Cc:     agross@...nel.org, andersson@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
        rafael@...nel.org, viresh.kumar@...aro.org, tglx@...utronix.de,
        maz@...nel.org, mani@...nel.org, robimarko@...il.com,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v3 4/5] dt-bindings: cpufreq: cpufreq-qcom-hw: Add SDX75
 compatible



On 9.06.2023 07:00, Pavan Kondeti wrote:
> On Wed, Jun 07, 2023 at 05:17:48PM +0530, Rohit Agarwal wrote:
>> Add compatible for EPSS CPUFREQ-HW on SDX75.
>>
>> Signed-off-by: Rohit Agarwal <quic_rohiagar@...cinc.com>
>> Acked-by: Viresh Kumar <viresh.kumar@...aro.org>
>> ---
>>  Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
>> index a6b3bb8..866ed2d 100644
>> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
>> @@ -36,6 +36,7 @@ properties:
>>                - qcom,sa8775p-cpufreq-epss
>>                - qcom,sc7280-cpufreq-epss
>>                - qcom,sc8280xp-cpufreq-epss
>> +              - qcom,sdx75-cpufreq-epss
>>                - qcom,sm6375-cpufreq-epss
>>                - qcom,sm8250-cpufreq-epss
>>                - qcom,sm8350-cpufreq-epss
> 
> This is a very basic question, not completely related to this patch.
> Apologies in advance.
> 
> What is the rationale for adding a new soc string under compatible and
> using it in the new soc device tree? Is it meant for documentation purpose?
> i.e one know what all SoCs / boards supported by this device node.
It's two-fold:

1. The device tree describes the hardware, and for lack of better terms (e.g.
   an SoC-specific version number of the block that is identical to all other
   implementations of that revision on all SoCs that use it), we tend to
   associate it with the SoC it's been (first) found on.

2. In case we ever needed to introduce a SoC-specific quirk, we can just add
   an of_is_compatible-sorta check to the driver and not have to update the
   device trees. This is very important for keeping backwards compatibility,
   as it's assumed that not everybody may be running the latest one. This
   means we have to avoid ABI breaks (unless we have *very* good reasons, like
   "this would have never worked anyway" or "it was not described properly
   and worked on this occasion by pure luck")

Konrad
> 
> I ask this because, we don't add these compatible strings in the driver
> [1] which means there is not SoC specific handling and there is no
> module load assist (module alias matching by user space based on device
> presence).
> 
> Thanks,
> Pavan