Skip to contentSkip to conversation

Patch "cpufreq: Do not clear real_cpus mask on policy init" has been added to the 4.9-stable tree

PATCH [email protected] 1 participant 1 message Nov 6, 2017

Subsystems (2)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

cpufreq: Do not clear real_cpus mask on policy init

to the 4.9-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-do-not-clear-real_cpus-mask-on-policy-init.patch
and it can be found in the queue-4.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From foo@baz Mon Nov 6 10:07:35 CET 2017

From: "Rafael J. Wysocki" <[email protected]>
Date: Sat, 7 Oct 2017 22:36:46 +0000
Subject: cpufreq: Do not clear real_cpus mask on policy init

From: "Rafael J. Wysocki" <[email protected]>

[ Upstream commit f451014692ae34e587b00de6745e16661cf734d8 ]

If new_policy is set in cpufreq_online(), the policy object has just been created and its real_cpus mask has been zeroed on allocation, and the driver's ->init() callback should not touch it.

It doesn't need to be cleared again, so don't do that.

---
 drivers/cpufreq/cpufreq.c |    2 --
 1 file changed, 2 deletions(-)
drivers/cpufreq/cpufreq.c +0 -2
@@ -1172,8 +1172,6 @@ static int cpufreq_online(unsigned int c
 	if (new_policy) {
 		/* related_cpus should at least include policy->cpus. */
 		cpumask_copy(policy->related_cpus, policy->cpus);
-		/* Clear mask of registered CPUs */
-		cpumask_clear(policy->real_cpus);
 	}
 
 	/*

Patches currently in stable-queue which might be from [email protected] are

queue-4.9/pm-wakeirq-report-a-wakeup_event-on-dedicated-wekup-irq.patch queue-4.9/cpufreq-do-not-clear-real_cpus-mask-on-policy-init.patch