On 22-10-20, 18:23, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> Subject: [PATCH] cpufreq: Avoid configuring old governors as default with intel_pstate
>
> Commit 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by
> default without HWP") was meant to cause intel_pstate without HWP
> to be used in the passive mode with the schedutil governor on top of
> it by default, but it missed the case in which either "ondemand" or
> "conservative" was selected as the default governor in the existing
> kernel config, in which case the previous old governor configuration
> would be used, causing the default legacy governor to be used on top
> of intel_pstate instead of schedutil.
>
> Address this by preventing "ondemand" and "conservative" from being
> configured as the default cpufreq governor in the case when schedutil
> is the default choice for the default governor setting.
>
> [Note that the default cpufreq governor can still be set via the
> kernel command line if need be and that choice is not limited,
> so if anyone really wants to use one of the legacy governors by
> default, it can be achieved this way.]
>
> Fixes: 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default without HWP")
> Cc: 5.8+ <stable@xxxxxxxxxxxxxxx> # 5.8+
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> ---
> drivers/cpufreq/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux-pm/drivers/cpufreq/Kconfig
> ===================================================================
> --- linux-pm.orig/drivers/cpufreq/Kconfig
> +++ linux-pm/drivers/cpufreq/Kconfig
> @@ -71,6 +71,7 @@ config CPU_FREQ_DEFAULT_GOV_USERSPACE
>
> config CPU_FREQ_DEFAULT_GOV_ONDEMAND
> bool "ondemand"
> + depends on !SMP || !X86_INTEL_PSTATE
> select CPU_FREQ_GOV_ONDEMAND
> select CPU_FREQ_GOV_PERFORMANCE
> help
> @@ -83,6 +84,7 @@ config CPU_FREQ_DEFAULT_GOV_ONDEMAND
>
> config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
> bool "conservative"
> + depends on !SMP || !X86_INTEL_PSTATE
While reading this first it felt like a SMP platforms related problem
(which I was surprised about), and then I understood what you are
doing.
I wonder if rewriting it this way makes it more readable with same
result eventually.
depends on !(X86_INTEL_PSTATE && SMP)
--
viresh
