linux-kernel - Re: [RFC PATCH] cpufreq: cpufreq-cpu0: do not allow transitions with regulators suspended

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Nov 2013 11:04:44 -0600
From:	Nishanth Menon <nm@...com>
To:	viresh kumar <viresh.kumar@...aro.org>
CC:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Shawn Guo <shawn.guo@...aro.org>
Subject: Re: [RFC PATCH] cpufreq: cpufreq-cpu0: do not allow transitions with
 regulators suspended

On 11/14/2013 10:46 AM, viresh kumar wrote:
> On Thursday 14 November 2013 07:57 PM, Nishanth Menon wrote:
>> I am guessing this is a little too early for restarting policy here
>> considering syscore_ops->resume is pretty early..
> 
> Yeah, looks like that..
> 
>> http://pastebin.mozilla.org/3602746 is the equivalent patch for v3.12
>> http://pastebin.mozilla.org/3602747 is the result.
> 
> Can you try this instead of last diff I sent?
> 
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index dc67fa0..e70e906 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1324,6 +1324,15 @@ static void handle_update(struct work_struct *work)
>                 container_of(work, struct cpufreq_policy, update);
>         unsigned int cpu = policy->cpu;
>         pr_debug("handle_update for cpu %u called\n", cpu);
> +
> +       if (has_target() && !policy->governor_enabled) {
> +               if ((ret = __cpufreq_governor(policy, CPUFREQ_GOV_START)) ||
> +                       (ret = __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS))) {
> +                       pr_err("%s: Failed to start governor\n", __func__);
> +                       goto fail;
> +               }
> +       }
> +
>         cpufreq_update_policy(cpu);
>  }
> 
> 
I think it is still too early to do so :(

equivalent patch: http://pastebin.mozilla.org/3603467 (with minor
changes for build)

Basic tests: http://pastebin.mozilla.org/3603456 (governor is
functional, but governor kicks in early before i2c is resumed)

With call stack: http://pastebin.mozilla.org/3603455 to highlight call
sequences

Seems like we might want to pause governor as early in the suspend
sequence as possible to allow SoC and regulator stuff to suspend
themselves without cpufreq interfering.. just my 2 cents..

-- 
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/