linux-kernel - Re: [PATCH V3 4/4] cpufreq: Add Kconfig option to enable/disable have_multiple

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: <CAKohponm_NpYJVcMVcXfMrn+cOFH6OZ2AnWSsVVeSzpmzLM4DQ@mail.gmail.com>
Date:	Wed, 20 Mar 2013 09:53:54 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	cpufreq@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org, linaro-kernel@...ts.linaro.org,
	robin.randhawa@....com, Steve.Bannister@....com,
	Liviu.Dudau@....com, charles.garcia-tobin@....com
Subject: Re: [PATCH V3 4/4] cpufreq: Add Kconfig option to enable/disable have_multiple_policies

On 20 March 2013 05:50, Rafael J. Wysocki <rjw@...k.pl> wrote:
> On Thursday, March 14, 2013 08:39:55 AM Viresh Kumar wrote:
>> On 14 March 2013 03:11, Rafael J. Wysocki <rjw@...k.pl> wrote:
>> > On Tuesday, March 12, 2013 08:55:12 AM Viresh Kumar wrote:
>> >> On 12 March 2013 07:38, Rafael J. Wysocki <rjw@...k.pl> wrote:
>> >> > One more question before I apply it.
>> >> >
>> >> > Is there any architecture/platform that will set
>> >> > CONFIG_CPU_FREQ_HAVE_MULTIPLE_POLICIES and keep have_multiple_policies unset
>> >> > at the same time?
>> >>
>> >> No, they are redundant. That's why i have been forcing to drop this patch.
>> >
>> > I see.
>> >
>> > What about having the Kconfig option alone, however?
>>
>> Even that is not enough. We build multiplatform kernels and so need a
>> variable to be set by platform.
>
> Which means the Kconfig option and the field are not redundant in fact.

Yes. Redundant was the wrong word. Actually Kconfig option is just not required
as we can work efficiently without it.

> But do we need the field to reside in the policy structure?  It looks like
> it may just be a global bool variable

Yes. It is not per policy but per cpufreq driver. And this can be done
by sharing
a function from cpufreq core to driver. But when do you want me to
call this function
(which will set this global variable). If we do it from init, then we
will end up calling it
again and again. Then it has to be called before calling
cpufreq_register_driver(),
as init() gets called internally.

> (in which case the Kconfig option could be dropped IMO).

We are aligned now :)

> Is there any particular reason to put that thing into
> struct cpufreq_policy?

Just the problem i mentioned to you.
--
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/