linux-kernel - Re: [RFC PATCH 1/4] dt-bindings: cpufreq-qcom-hw: Move clocks to CPU nodes

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: <20220718204651.GA3505083-robh@kernel.org>
Date:   Mon, 18 Jul 2022 14:46:51 -0600
From:   Rob Herring <robh@...nel.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Andy Gross <agross@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Johan Hovold <johan@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/4] dt-bindings: cpufreq-qcom-hw: Move clocks to CPU
 nodes

On Wed, Jul 13, 2022 at 12:22:56PM +0530, Viresh Kumar wrote:
> cpufreq-hw is a hardware engine, which takes care of frequency
> management for CPUs. The engine manages the clocks for CPU devices, but
> it isn't the end consumer of the clocks, which are the CPUs in this
> case.

The question is really where does the clock mux live?

> For this reason, it looks incorrect to keep the clock related properties
> in the cpufreq-hw node. They should really be present at the end user,
> i.e. the CPUs.

The issue is that the CPU itself probably only has 1 clock input (at 
least for its core frequency). Listing out all possible clock sources in 
CPU node 'clocks' is wrong too.

> The case was simple currently as all the devices, i.e. the CPUs, that
> the engine manages share the same clock names. What if the clock names
> are different for different CPUs or clusters ? How will keeping the
> clock properties in the cpufreq-hw node work in that case ?
> 
> This design creates further problems for frameworks like OPP, which
> expects all such details (clocks) to be present in the end device node
> itself, instead of another related node.
> 
> Move the clocks properties to the node that uses them instead.

What's the purpose of freq-domain binding now? I thought the idea was to 
use that instead of clocks directly.

Rob