On 01/27/2015 12:36 AM, Viresh Kumar wrote:
Later commits would change the way policies are managed today. Policies wouldn't be freed on cpu hotplug (currently they aren't freed on suspend), and while the CPU is offline, the sysfs cpufreq files would still be present.
Because we don't mark policy->governor as NULL, it still contains pointer of the last governor it used. And when we read the 'scaling_governor' file, it shows the old value.
To prevent from this, mark policy->governor as NULL after we have issued CPUFREQ_GOV_POLICY_EXIT event for its governor.
I don't see anything wrong with scaling_governor showing the last used governor when the CPUs are just logically hotplug removed. In the physical hotplug case, the whole directory would go away and the policy would be freed. So, this is not a concern there.
Also, longer term (after your series goes in), I think we actually should NOT send POLICY_EXIT on just logical hotplug. That way, the governor tunables are not lost across a logical hotplug.
-Saravana
Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
drivers/cpufreq/cpufreq.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 21c8ef6073d7..ed36c09f83cc 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1032,9 +1032,6 @@ static struct cpufreq_policy *cpufreq_policy_restore(unsigned int cpu) } read_unlock_irqrestore(&cpufreq_driver_lock, flags);
- if (policy)
policy->governor = NULL;- return policy; }
@@ -1466,6 +1463,8 @@ static int __cpufreq_remove_dev_finish(struct device *dev,
if (!cpufreq_suspended) cpufreq_policy_free(policy);
elsepolicy->governor = NULL;