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] [day] [month] [year] [list]
Date:   Tue, 8 Nov 2022 15:45:32 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc:     andersson@...nel.org, viresh.kumar@...aro.org,
        krzysztof.kozlowski+dt@...aro.org, rafael@...nel.org,
        robh+dt@...nel.org, johan@...nel.org, devicetree@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Sudeep Holla <sudeep.holla@....com>, linux-pm@...r.kernel.org
Subject: Re: [PATCH v4 0/3] qcom-cpufreq-hw: Add CPU clock provider support

On Wed, Nov 02, 2022 at 02:38:15PM +0530, Manivannan Sadhasivam wrote:
> Hello,
> 
> This series adds clock provider support to the Qcom CPUFreq driver for
> supplying the clocks to the CPU cores in Qcom SoCs.
> 
> The Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply
> clocks to the CPU cores. But this is not represented clearly in devicetree.
> There is no clock coming out of the CPUFreq HW node to the CPU. This created
> an issue [1] with the OPP core when a recent enhancement series was submitted.
> Eventhough the issue got fixed in the OPP framework in the meantime, that's
> not a proper solution and this series aims to fix it properly.
> 
> There was also an attempt made by Viresh [2] to fix the issue by moving the
> clocks supplied to the CPUFreq HW node to the CPU. But that was not accepted
> since those clocks belong to the CPUFreq HW node only.
> 
> The proposal here is to add clock provider support to the Qcom CPUFreq HW
> driver to supply clocks to the CPUs that comes out of the EPSS/OSM block.
> This correctly reflects the hardware implementation.
>

Just curious as who will be the consumer of this CPU clock information ?
Traditionally it was cpufreq that needed this information. But now with
this series, it is bit convoluted IMO as the clocks is depending on the
CPUFreq information indirectly and not used by cpufreq.

Whoever is the consumer of this clock, why can't they use cpufreq information ?

I did a quick check and couldn't find the info I am requesting here, sorry if
it is already answered/discussed. Please just point me the url.

-- 
Regards,
Sudeep

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ