This is a note to let you know that I've just added the patch titled
cpufreq: Skip current frequency initialization for ->setpolicy drivers
to the 3.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
cpufreq-skip-current-frequency-initialization-for-setpolicy-drivers.patch
and it can be found in the queue-3.13 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From 2ed99e39cb9392312c100d9da591c20641c64d12 Mon Sep 17 00:00:00 2001
From: "Rafael J. Wysocki" <rafael.j.wysocki@xxxxxxxxx>
Date: Wed, 12 Mar 2014 21:49:33 +0100
Subject: cpufreq: Skip current frequency initialization for ->setpolicy drivers
From: "Rafael J. Wysocki" <rafael.j.wysocki@xxxxxxxxx>
commit 2ed99e39cb9392312c100d9da591c20641c64d12 upstream.
After commit da60ce9f2fac (cpufreq: call cpufreq_driver->get() after
calling ->init()) __cpufreq_add_dev() sometimes fails for CPUs handled
by intel_pstate, because that driver may return 0 from its ->get()
callback if it has not run long enough to collect enough samples on the
given CPU. That didn't happen before commit da60ce9f2fac which added
policy->cur initialization to __cpufreq_add_dev() to help reduce code
duplication in other cpufreq drivers.
However, the code added by commit da60ce9f2fac need not be executed
for cpufreq drivers having the ->setpolicy callback defined, because
the subsequent invocation of cpufreq_set_policy() will use that
callback to initialize the policy anyway and it doesn't need
policy->cur to be initialized upfront. The analogous code in
cpufreq_update_policy() is also unnecessary for cpufreq drivers
having ->setpolicy set and may be skipped for them as well.
Since intel_pstate provides ->setpolicy, skipping the upfront
policy->cur initialization for cpufreq drivers with that callback
set will cover intel_pstate and the problem it's been having after
commit da60ce9f2fac will be addressed.
Fixes: da60ce9f2fac (cpufreq: call cpufreq_driver->get() after calling ->init())
References: https://bugzilla.kernel.org/show_bug.cgi?id=71931
Reported-and-tested-by: Patrik Lundquist <patrik.lundquist@xxxxxxxxx>
Acked-by: Dirk Brandewie <dirk.j.brandewie@xxxxxxxxx>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
drivers/cpufreq/cpufreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1051,7 +1051,7 @@ static int __cpufreq_add_dev(struct devi
goto err_set_policy_cpu;
}
- if (cpufreq_driver->get) {
+ if (cpufreq_driver->get && !cpufreq_driver->setpolicy) {
policy->cur = cpufreq_driver->get(policy->cpu);
if (!policy->cur) {
pr_err("%s: ->get() failed\n", __func__);
@@ -2051,7 +2051,7 @@ int cpufreq_update_policy(unsigned int c
* BIOS might change freq behind our back
* -> ask driver for current freq and notify governors about a change
*/
- if (cpufreq_driver->get) {
+ if (cpufreq_driver->get && !cpufreq_driver->setpolicy) {
new_policy.cur = cpufreq_driver->get(cpu);
if (!policy->cur) {
pr_debug("Driver did not initialize current freq");
Patches currently in stable-queue which might be from rafael.j.wysocki@xxxxxxxxx are
queue-3.13/cpufreq-use-cpufreq_cpu_get-to-avoid-cpufreq_get-race-conditions.patch
queue-3.13/acpi-resources-ignore-invalid-acpi-device-resources.patch
queue-3.13/cpufreq-skip-current-frequency-initialization-for-setpolicy-drivers.patch
queue-3.13/acpi-ec-clear-stale-ec-events-on-samsung-systems.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html