Some cpufreq drivers have a get() function which can return an unreliable
frequency. This can cause issues when switching governors. For instance,
a CPU would be on performance governor and have it's frequency (and
policy->cur) set to max. When the governor is switched to userspace, the
policy->cur is re-used, but it is checked against the frequency returned
by the driver's get() function. If it's different, the frequency will
get set to the new (incorrect) value.
To avoid this, add a flag that avoids this verify step on governor start
if the cpufreq driver opts in to it.
Since there are no users of this flag, no functional changes are
introduced here.
Cc: Beata Michalska <beata.michalska@arm.com>
Signed-off-by: Prashant Malani <pmalani@google.com>
---
drivers/cpufreq/cpufreq.c | 3 ++-
include/linux/cpufreq.h | 10 ++++++++++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b8937737d096..72e6552a40ea 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2482,7 +2482,8 @@ int cpufreq_start_governor(struct cpufreq_policy *policy)
pr_debug("%s: for CPU %u\n", __func__, policy->cpu);
- cpufreq_verify_current_freq(policy, false);
+ if (!(cpufreq_driver->flags & CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START))
+ cpufreq_verify_current_freq(policy, false);
if (policy->governor->start) {
ret = policy->governor->start(policy);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 95f3807c8c55..1ebc12fcc905 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -474,6 +474,16 @@ struct cpufreq_driver {
*/
#define CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING BIT(6)
+/*
+ * Set by drivers which want cpufreq core to avoid verifying that the current
+ * frequency of the policy matches the frequency returned by the driver's get()
+ * function. The get() function on certain drivers returns unreliable values,
+ * and this can result in the frequency (and consequently system performance)
+ * being reduced even though the governor didn't want the frequencies to be
+ * reduced.
+ */
+#define CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START BIT(7)
+
int cpufreq_register_driver(struct cpufreq_driver *driver_data);
void cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
--
2.51.0.rc2.233.g662b1ed5c5-goog
On 23-08-25, 00:17, Prashant Malani wrote: > Some cpufreq drivers have a get() function which can return an unreliable > frequency. This can cause issues when switching governors. For instance, > a CPU would be on performance governor and have it's frequency (and > policy->cur) set to max. When the governor is switched to userspace, the > policy->cur is re-used, but it is checked against the frequency returned > by the driver's get() function. If it's different, the frequency will > get set to the new (incorrect) value. > > To avoid this, add a flag that avoids this verify step on governor start > if the cpufreq driver opts in to it. > > Since there are no users of this flag, no functional changes are > introduced here. > > Cc: Beata Michalska <beata.michalska@arm.com> > Signed-off-by: Prashant Malani <pmalani@google.com> > --- > drivers/cpufreq/cpufreq.c | 3 ++- > include/linux/cpufreq.h | 10 ++++++++++ > 2 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index b8937737d096..72e6552a40ea 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -2482,7 +2482,8 @@ int cpufreq_start_governor(struct cpufreq_policy *policy) > > pr_debug("%s: for CPU %u\n", __func__, policy->cpu); > > - cpufreq_verify_current_freq(policy, false); > + if (!(cpufreq_driver->flags & CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START)) > + cpufreq_verify_current_freq(policy, false); I don't think it is okay to do this to hide a driver's failure to return the right frequency. What about all the other places where get() is still used ? Won't that cause similar issues elsewhere ? The driver must be fixed for this, not the core. The core is doing the right thing here, asking the driver to return the current frequency. If the driver is unsure, it can just return the current frequency from policy->cur instead. -- viresh
On Mon, Aug 25, 2025 at 10:26:41AM +0530, Viresh Kumar wrote: > On 23-08-25, 00:17, Prashant Malani wrote: > > Some cpufreq drivers have a get() function which can return an unreliable > > frequency. This can cause issues when switching governors. For instance, > > a CPU would be on performance governor and have it's frequency (and > > policy->cur) set to max. When the governor is switched to userspace, the > > policy->cur is re-used, but it is checked against the frequency returned > > by the driver's get() function. If it's different, the frequency will > > get set to the new (incorrect) value. > > > > To avoid this, add a flag that avoids this verify step on governor start > > if the cpufreq driver opts in to it. > > > > Since there are no users of this flag, no functional changes are > > introduced here. > > > > Cc: Beata Michalska <beata.michalska@arm.com> > > Signed-off-by: Prashant Malani <pmalani@google.com> > > --- > > drivers/cpufreq/cpufreq.c | 3 ++- > > include/linux/cpufreq.h | 10 ++++++++++ > > 2 files changed, 12 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > > index b8937737d096..72e6552a40ea 100644 > > --- a/drivers/cpufreq/cpufreq.c > > +++ b/drivers/cpufreq/cpufreq.c > > @@ -2482,7 +2482,8 @@ int cpufreq_start_governor(struct cpufreq_policy *policy) > > > > pr_debug("%s: for CPU %u\n", __func__, policy->cpu); > > > > - cpufreq_verify_current_freq(policy, false); > > + if (!(cpufreq_driver->flags & CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START)) > > + cpufreq_verify_current_freq(policy, false); > > I don't think it is okay to do this to hide a driver's failure to > return the right frequency. What about all the other places where > get() is still used ? Won't that cause similar issues elsewhere ? > > The driver must be fixed for this, not the core. The core is doing the Agreed. --- BR Beata > right thing here, asking the driver to return the current frequency. > If the driver is unsure, it can just return the current frequency from > policy->cur instead. > > -- > viresh
© 2016 - 2025 Red Hat, Inc.