linux-kernel - Re: [RFC PATCH] cpufreq: Calling init() of cpufreq

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, 22 Mar 2018 05:35:20 +0000
From:   "Yang, Shunyong" <shunyong.yang@...-semitech.com>
To:     "viresh.kumar@...aro.org" <viresh.kumar@...aro.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Zheng, Joey" <yu.zheng@...-semitech.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "rjw@...ysocki.net" <rjw@...ysocki.net>,
        "Wang, Dongsheng" <dongsheng.wang@...-semitech.com>
Subject: Re: [RFC PATCH] cpufreq: Calling init() of cpufreq_driver  when
 policy inactive cpu online

Hi, Kumar

On Thu, 2018-03-22 at 11:30 +0800, Viresh Kumar wrote:
> On 21-03-18, 18:21, Shunyong Yang wrote:
> > 
> > When multiple cpus are related in one cpufreq policy, the first
> > online cpu
> > will be chosen by default to handle cpufreq operations. In a CPPC
> > case,
> > let's take two related cpus, cpu0 and cpu1 as an example.
> > 
> > After system start, cpu0 is the first online cpu. Cpufreq policy
> > will be
> > allocated and init() in cpufreq_driver will be called to initialize
> > cpu0's
> > perf capabilities and policy parameters.
> Not exactly. The init() is called to initialize stuff for all the
> CPUs that
> should be part of policy->related_cpus after init() has returned. So
> you should
> initialize perf capabilities for all of them.

In page 533 of ACPI 6.2 specificaiton, it says,

"Starting with ACPI Specification 6.2, all _CPC registers can be in
PCC, System Memory, System IO, or Functional Fixed Hardware address
spaces. OSPM support for this more flexible register space scheme is
indicated by the “Flexible Address Space for CPPC Registers” _OSC bit."

As _CPC register maybe in System Memory, System IO, or Functional Fixed
Hardware address spaces. I am not sure all architecture implementing
CPPC can return correct value before CPU come into online. That's the
reason I add the extra init() call.

BTW, I've tested on QDF2400 platform and it return correct value when
cpu1 is offline.

Do you know whether firmware can guarantee correct perf capabilities
regardless of CPU online/offline?

> 
> > 
> > When cpu1 is online, current code
> > will not call init() in cpufreq_driver as policy has been allocated
> > and
> > activated by cpu0. So, cpu1's perf capabilities are not initialized
> > (all 0s).
> > 
> > When cpu0 is offline, policy->cpu will be shifted to cpu1. As
> > cpu1's perf
> > capabilities are 0s, speed change will not take effect when setting
> > speed.
> > 
> > This patch adds calling init() of cpufreq_driver when policy
> > inactive cpu
> > comes to online.
> No CPU should be inactive here, its just that you haven't initialized
> it
> properly.
> 

I mean the policy is handled(active) by the first online cpu's (cpu0)
perf capabilities. Not handled (inactive) by the one's just come into
online (cpu1). Sorry for this.

Thanks.
Shunyong.

> And we are not going to call init() multiple times for a group of
> CPUs. That's
> not what the purpose of init() is.
>