[PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification

Prashant Malani posted 2 patches 1 month, 1 week ago
[PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification
Posted by Prashant Malani 1 month, 1 week ago
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
Re: [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification
Posted by Viresh Kumar 1 month, 1 week ago
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
Re: [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification
Posted by Beata Michalska 1 month, 1 week ago
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