On Wed, May 10, 2023 at 7:43 AM Wyes Karny <wyes.karny@xxxxxxx> wrote: > > Hi Rafael, > > Thanks for reviewing the patch. > > On 09 May 20:39, Rafael J. Wysocki wrote: > ------------------------------------------>8-------------------------------------- > > > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > > > > index 2548ec92faa2..007893514c87 100644 > > > > --- a/drivers/cpufreq/intel_pstate.c > > > > +++ b/drivers/cpufreq/intel_pstate.c > > > > @@ -2698,8 +2698,6 @@ static int __intel_pstate_cpu_init(struct cpufreq_policy *policy) > > > > > > > > intel_pstate_init_acpi_perf_limits(policy); > > > > > > > > - policy->fast_switch_possible = true; > > > > - > > > > return 0; > > > > } > > > > > > > > @@ -2955,6 +2953,7 @@ static int intel_cpufreq_cpu_init(struct cpufreq_policy *policy) > > > > if (ret) > > > > return ret; > > > > > > > > + policy->fast_switch_possible = true; > > > > I'm not sure what this is about. Is it a cleanup of intel_pstate? > > This patch intends to remove fast_switch_possible flag dependency from > drivers which only use adjust_perf as frequency/pref update callback. As > intel_pstate and amd_pstate driver has only adjust_perf and not > fast_switch, therefore I'm removing that flag from these drivers. But > intel_cpufreq has fast_switch therefore, only adding that flag for > intel_cpufreq driver. But is it really better to change it? It works correctly as-is AFAICS. In any case, the intel_pstate change should be a separate patch, because it is not directly related to the other changes in the $subject one IMV.
