On Tue, Dec 18, 2012 at 12:29 AM, Sonny Rao <[email protected]> wrote: > The cpu_thermal generic thermal management code has a bug where once > max cpu frequency has been lowered in sysfs (scaling_max_freq) it is > not possible to raise the max back up later. The bug is that the > notifer gets called by __cpufreq_set_policy() before the user policy > max is raised, and is incorrectly trying to enforce the max frequency > policy even when we are trying to change the policy. It is also not > clear why this driver is looking at the user policy since it is > primarily supposed to enforce thermal policy, not user set policy. > > Signed-off-by: Sonny Rao <[email protected]> > --- > drivers/thermal/cpu_cooling.c | 4 ---- > 1 files changed, 0 insertions(+), 4 deletions(-) > > diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c > index 836828e..63bc708 100644 > --- a/drivers/thermal/cpu_cooling.c > +++ b/drivers/thermal/cpu_cooling.c > @@ -219,10 +219,6 @@ static int cpufreq_thermal_notifier(struct > notifier_block *nb, > if (cpumask_test_cpu(policy->cpu, ¬ify_device->allowed_cpus)) > max_freq = notify_device->cpufreq_val; > > - /* Never exceed user_policy.max*/ > - if (max_freq > policy->user_policy.max) > - max_freq = policy->user_policy.max; > - > if (policy->max != max_freq) > cpufreq_verify_within_limits(policy, 0, max_freq); > > -- > 1.7.7.3 >
Sonny's change matches what the "ACPI version" of this code (drivers/acpi/processor_thermal.c) does as well. I would certainly be interested to know why the code was added here in the first place. Amit: do you know? Reviewed-by: Doug Anderson <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
