linux-kernel - Re: [RFC] cpufreq: Add ->get

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:	Fri, 10 Jul 2015 01:26:23 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	linaro-kernel@...ts.linaro.org, linux-pm@...r.kernel.org,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] cpufreq: Add ->get_rate() driver callback

On Thursday, July 09, 2015 10:29:02 AM Viresh Kumar wrote:
> On 09-07-15, 01:41, Rafael J. Wysocki wrote:
> > On Wednesday, July 08, 2015 04:07:32 PM Viresh Kumar wrote:
> > > CPUFreq drivers today support a ->get(cpu) callback, which returns
> > > current rate of a CPU. The problem with ->get() is that it takes a cpu
> > > number as parameter and this unnecessarily makes things complex.
> > > 
> > > Firstly the core gets the cpu number by doing operation 'policy->cpu' on
> > > the policy and then many drivers need to get the policy back and so do
> > > cpufreq_cpu_get(cpu) on the passed cpu.
> > > 
> > > As cpufreq core works on policies, it would be better if we pass them
> > > 'policy' directly and drivers can use policy->cpu if that's all they
> > > need.
> > > 
> > > Hence, this patch adds in another callback, ->get_rate() which does
> > > exactly the same work as ->get(), just that we pass 'policy' as
> > > parameter instead of 'cpu'.
> > > 
> > > The plan is to migrate all drivers to this new callback and remove
> > > ->get() after that.
> > > 
> > > Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
> > > ---
> > > Hi Rafael,
> > > 
> > > I hope you are fine with this stuff :), once you approve I will get
> > > other patches to migrate existing drivers to this interface.
> > 
> > I'm generally fine with it, but please target it at 4.4 at the earliest.
> 
> Sure, but I was a bit curious on why 4.4 and not 4.3 ?

I already have 20+ cpufreq patches from you for 4.3 needing my attention,
not to mention the Ashwin's CPPC series.

> as we are still at 4.2-rc1 today, and these patches can be done fairly
> quickly.

*You* can do them faily quickly.  Say if all of the outstanding cpufreq
patches are queued up for 4.3, then it will be the time to submit more.
Otherwise I'll just have an ever growing queue of patches to process
which won't speed up things at all.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/