linux-kernel - Re: [PATCH] cpufreq: Make sure CPU is running on a freq from freq-table

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:	Fri, 22 Nov 2013 15:43:43 -0600
From:	Nishanth Menon <nm@...com>
To:	viresh kumar <viresh.kumar@...aro.org>
CC:	<rjw@...ysocki.net>, <linaro-kernel@...ts.linaro.org>,
	<patches@...aro.org>, <cpufreq@...r.kernel.org>,
	<linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<shawn.guo@...aro.org>, <ceh@...com>
Subject: Re: [PATCH] cpufreq: Make sure CPU is running on a freq from freq-table

On 11/22/2013 01:03 AM, viresh kumar wrote:
> On Thursday 21 November 2013 12:39 PM, Viresh Kumar wrote:

[...]
> Copying another mail from Nishant here to get my cc'list back..
> 
> On Friday 22 November 2013 05:12 AM, Nishanth Menon wrote:
>> I gave this a quick run on my 3.12 kernel:
>> http://pastebin.mozilla.org/3649730 is what I applied and output
>> http://pastebin.mozilla.org/3649729
>>
>> I need to see what I might have mucked up.. or see if I can test this
>> on 3.13 master on a different board (since OMAP5 wont boot in master
>> without clock dts nodes :()..
> 
> This happened because of common sense, which was missing in my patch :)
> 
> Try this over existing patch:


Works like a charm :) thanks.

http://pastebin.mozilla.org/3655494 -> simple Ondemand governor testing.
http://pastebin.mozilla.org/3655493 -> simple Userspace governor testing.

> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 6e8b226..e403388 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1126,13 +1126,19 @@ static int __cpufreq_add_dev(struct device *dev, struct
> subsys_interface *sif,
>          * In case where CPU is already running on one of the frequencies
>          * present in freq-table, this would turn into a dummy call as
>          * __cpufreq_driver_target() would return early.
> +        *
> +        * We are passing target-freq as "policy->cur - 1" otherwise
> +        * __cpufreq_driver_target() would simply fail, as policy->cur will be
> +        * equal to target-freq.
>          */
>         if (has_target()) {
> -               ret = __cpufreq_driver_target(policy, policy->cur,
> +               ret = __cpufreq_driver_target(policy, policy->cur - 1,
>                                 CPUFREQ_RELATION_L);
> -               if (ret)
> +               if (ret) {
>                         pr_err("%s: Unable to set frequency from table: %d\n",
>                                         __func__, ret);
> +                       goto err_out_unregister;
> +               }
>         }
> 
>         /* related cpus should atleast have policy->cpus */
> 
-- 
Regards,
Nishanth Menon
--
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/