linux-kernel - Re: [PATCH 1/3] dt-bindings: cpufreq: qcom-cpufreq-nvmem: make cpr bindings optional

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:   Sun, 22 Jan 2023 15:13:21 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Christian Marangi <ansuelsmth@...il.com>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Ilia Lin <ilia.lin@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
        Yassine Oudjana <y.oudjana@...tonmail.com>,
        linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: cpufreq: qcom-cpufreq-nvmem: make cpr
 bindings optional

On 22/01/2023 15:05, Christian Marangi wrote:
> On Sun, Jan 22, 2023 at 02:57:07PM +0100, Krzysztof Kozlowski wrote:
>> On 21/01/2023 01:01, Christian Marangi wrote:
>>> The qcom-cpufreq-nvmem driver also supports legacy devices pre-cpr that
>>> doesn't have power-domains. When the schema was introduced, it was
>>> wrongly set to always require these binding but this is not the case for
>>> legacy device that base everything on nvmem cells and multiple microvolt
>>
>> What is a "legacy device"? Why do you adjust bindings to legacy device?
>> Can't you just fix the DTS on these devices?
>>
> 
> With legacy I mean device where cpr (core power reduction) wasn't a
> thing and qcom used a different way to select the microvolt for the opp.
> 
> There is nothing in the related DTS to fix since they are not broken.
> The driver doesn't enforce cpr presence and supports both new and old
> implementation...
> 
> Setting the cpr as a required binding was wrong from the start. It was
> probably done when qcs404 was introduced and they had this bright idea
> of creating the schema and ignoring the other kind of configuration the
> driver supports.
> 
> Since now we want to send opp for ipq8064 that use the old
> implementation this fixup is required.
> 
> Probably I should drop the legacy term and just say that the driver
> supports 2 different configuration and the following schema permits only
> one?

Yes, it would be clearer.

Best regards,
Krzysztof