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: <1521696919.2792.19.camel@hxt-semitech.com>
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.
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ