cpufreq: Fix policy initialization for internal governor drivers
PATCH 1/1 cpufreq: Fix policy initialization for internal governor drivers
From: Rafael J. Wysocki <[email protected]>
Before commit 1e4f63aecb53 ("cpufreq: Avoid creating excessively large stack frames") the initial value of the policy field in struct cpufreq_policy set by the driver's ->init() callback was implicitly passed from cpufreq_init_policy() to cpufreq_set_policy() if the default governor was neither "performance" nor "powersave". After that commit, however, cpufreq_init_policy() must take that case into consideration explicitly and handle it as appropriate, so make that happen.
---
Note that I'm going to fast-track this patch for 5.6-rc4 which means that it will go into my linux-next branch as soon as it shows up in the lists.
Thanks and sorry for the breakage!
--- drivers/cpufreq/cpufreq.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
drivers/cpufreq/cpufreq.c +10 -2
@@ -1076,9 +1076,17 @@ static int cpufreq_init_policy(struct cp pol = policy->last_policy; }else if (def_gov) { pol =cpufreq_parse_policy (def_gov->name); - }else { -return -ENODATA ; +/* +* In case the default governor is neiter "performance" +* nor "powersave", fall back to the initial policy +* value set by the driver. +*/ +if (pol ==CPUFREQ_POLICY_UNKNOWN ) + pol = policy->policy; } +if (pol !=CPUFREQ_POLICY_PERFORMANCE && + pol !=CPUFREQ_POLICY_POWERSAVE ) +return -ENODATA ; }return cpufreq_set_policy (policy, gov, pol);
Quoted 41 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
Before commit
1e4f63aecb53("cpufreq: Avoid creating excessively large stack frames") the initial value of the policy field in structcpufreq_policyset by the driver's ->init() callback was implicitly passed fromcpufreq_init_policy()tocpufreq_set_policy()if the default governor was neither "performance" nor "powersave". After that commit, however,cpufreq_init_policy()must take that case into consideration explicitly and handle it as appropriate, so make that happen.Fixes 1e4f63aecb53 ("cpufreq: Avoid creating excessively large stack frames")Reported-by Artem Bityutskiy <[email protected]>Cc 5.4+ <[email protected]> # 5.4+Signed-off-by Rafael J. Wysocki <[email protected]>---
Note that I'm going to fast-track this patch for 5.6-rc4 which means that it will go into my linux-next branch as soon as it shows up in the lists.
Thanks and sorry for the breakage!
--- drivers/cpufreq/cpufreq.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)Index:
linux-pm/drivers/cpufreq/cpufreq.c
===================================================================drivers/cpufreq/cpufreq.c +4
-2@@ -1076,9 +1076,17 @@ static int cpufreq_init_policy(struct cp pol = policy->last_policy; }else if (def_gov) { pol =cpufreq_parse_policy (def_gov->name); - }else { -return -ENODATA ; +/* +* In case the default governor is neiter "performance" +* nor "powersave", fall back to the initial policy +* value set by the driver.
drivers/cpufreq/cpufreq.c static int cpufreq_init_policy(struct cp · line 1092
Quoted 10 lines
drivers/cpufreq/cpufreq.c +6
-0+*/ +if (pol ==CPUFREQ_POLICY_UNKNOWN ) + pol = policy->policy; } +if (pol !=CPUFREQ_POLICY_PERFORMANCE && + pol !=CPUFREQ_POLICY_POWERSAVE ) +return -ENODATA ; }return cpufreq_set_policy (policy, gov, pol);
Signature · 1 line
viresh
Quoted 11 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
Before commit
1e4f63aecb53("cpufreq: Avoid creating excessively large stack frames") the initial value of the policy field in structcpufreq_policyset by the driver's ->init() callback was implicitly passed fromcpufreq_init_policy()tocpufreq_set_policy()if the default governor was neither "performance" nor "powersave". After that commit, however,cpufreq_init_policy()must take that case into consideration explicitly and handle it as appropriate, so make that happen.
Quoted 5 lines
Fixes 1e4f63aecb53 ("cpufreq: Avoid creating excessively large stack frames")Reported-by Artem Bityutskiy <[email protected]>Cc 5.4+ <[email protected]> # 5.4+Signed-off-by Rafael J. Wysocki <[email protected]>
Many thanks, fixes the issue.
Artem.