[PATCH 1/3] cpufreq: Fix typo in comment

[PATCH 1/3] cpufreq: Fix typo in comment

[Viresh Kumar]

Replace "diver" with "driver" in the comment describing
CPUFREQ_NEED_UPDATE_LIMITS.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 include/linux/cpufreq.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 2ab691828e48..4d4b4ed24b30 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -434,7 +434,7 @@ struct cpufreq_driver {
 /*
  * Set by drivers that need to update internal upper and lower boundaries along
  * with the target frequency and so the core and governors should also invoke
- * the diver if the target frequency does not change, but the policy min or max
+ * the driver if the target frequency does not change, but the policy min or max
  * may have changed.
  */
 #define CPUFREQ_NEED_UPDATE_LIMITS		BIT(0)
-- 
2.31.1.272.g89b43f80a514

[PATCH 2/3] cpufreq: Avoid redundant target() calls for unchanged limits

[Viresh Kumar]

Drivers setting CPUFREQ_NEED_UPDATE_LIMITS expect target() to be
invoked even if the target frequency remains unchanged, so they can
update their internal policy limits state.

Currently the core invokes target() unconditionally whenever the
requested frequency matches policy->cur for such drivers, even if
policy->min and policy->max haven't changed since the previous update.

Track pending policy limit updates explicitly and skip redundant
target() invocations when neither the target frequency nor the
effective limits changed.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/cpufreq/cpufreq.c      | 31 ++++++++++++++++++++++---------
 drivers/cpufreq/intel_pstate.c |  1 +
 include/linux/cpufreq.h        |  3 +++
 3 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 44eb1b7e7fc1..225228e9f4ed 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2366,9 +2366,13 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
 	 * exactly same freq is called again and so we can save on few function
 	 * calls.
 	 */
-	if (target_freq == policy->cur &&
-	    !(cpufreq_driver->flags & CPUFREQ_NEED_UPDATE_LIMITS))
-		return 0;
+	if (target_freq == policy->cur) {
+		if (!(cpufreq_driver->flags & CPUFREQ_NEED_UPDATE_LIMITS) ||
+		    !policy->update_limits)
+			return 0;
+
+		policy->update_limits = false;
+	}
 
 	if (cpufreq_driver->target) {
 		/*
@@ -2620,6 +2624,7 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
 {
 	struct cpufreq_policy_data new_data;
 	struct cpufreq_governor *old_gov;
+	unsigned int freq;
 	int ret;
 
 	memcpy(&new_data.cpuinfo, &policy->cpuinfo, sizeof(policy->cpuinfo));
@@ -2652,12 +2657,20 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
 	 * compiler optimizations around them because they may be accessed
 	 * concurrently by cpufreq_driver_resolve_freq() during the update.
 	 */
-	WRITE_ONCE(policy->max, __resolve_freq(policy, new_data.max,
-					       new_data.min, new_data.max,
-					       CPUFREQ_RELATION_H));
-	new_data.min = __resolve_freq(policy, new_data.min, new_data.min,
-				      new_data.max, CPUFREQ_RELATION_L);
-	WRITE_ONCE(policy->min, new_data.min > policy->max ? policy->max : new_data.min);
+	freq = __resolve_freq(policy, new_data.max, new_data.min, new_data.max,
+			      CPUFREQ_RELATION_H);
+	if (freq != policy->max) {
+		WRITE_ONCE(policy->max, freq);
+		policy->update_limits = true;
+	}
+
+	freq = __resolve_freq(policy, new_data.min, new_data.min, new_data.max,
+			      CPUFREQ_RELATION_L);
+	freq = min(freq, policy->max);
+	if (freq != policy->min) {
+		WRITE_ONCE(policy->min, freq);
+		policy->update_limits = true;
+	}
 
 	trace_cpu_frequency_limits(policy);
 
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 1292da53e5fc..7f19ec6b70ba 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2942,6 +2942,7 @@ static void intel_pstate_adjust_policy_max(struct cpudata *cpu,
 	    policy->max > cpu->pstate.max_freq) {
 		pr_debug("policy->max > max non turbo frequency\n");
 		policy->max = policy->cpuinfo.max_freq;
+		policy->update_limits = true;
 	}
 }
 
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 4d4b4ed24b30..ae9d1ce4f49c 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -146,6 +146,9 @@ struct cpufreq_policy {
 	/* Per policy boost supported flag. */
 	bool			boost_supported;
 
+	/* Pending policy->min/max update for the driver */
+	bool			update_limits;
+
 	 /* Cached frequency lookup from cpufreq_driver_resolve_freq. */
 	unsigned int cached_target_freq;
 	unsigned int cached_resolved_idx;
-- 
2.31.1.272.g89b43f80a514

[PATCH V2 3/3] cpufreq: conservative: Simplify frequency limit handling

[Viresh Kumar]

From: Lifeng Zheng <zhenglifeng1@huawei.com>

cs_dbs_update() performs explicit checks against policy->min/max
before updating the target frequency. These checks are redundant as
__cpufreq_driver_target() already clamps the requested frequency to
the valid policy limits.

Remove the unnecessary boundary checks and simplify the update logic.

This also fixes an issue introduced by commit 00bfe05889e9 ("cpufreq:
conservative: Decrease frequency faster for deferred updates"), where
stale target comparisons could cause frequency updates to be skipped
entirely after deferred adjustments.

Closes: https://lore.kernel.org/all/20260421123545.1745998-1-zhenglifeng1@huawei.com/
Fixes: 00bfe05889e9 ("cpufreq: conservative: Decrease frequency faster for deferred updates")
Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Co-developed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V2:
- This fixes the issue raised by Lifeng in a completely different way.

 drivers/cpufreq/cpufreq_conservative.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
index df01d33993d8..0b32ae28ec85 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -103,10 +103,6 @@ static unsigned int cs_dbs_update(struct cpufreq_policy *policy)
 	if (load > dbs_data->up_threshold) {
 		dbs_info->down_skip = 0;
 
-		/* if we are already at full speed then break out early */
-		if (requested_freq == policy->max)
-			goto out;
-
 		requested_freq += freq_step;
 		if (requested_freq > policy->max)
 			requested_freq = policy->max;
@@ -124,13 +120,7 @@ static unsigned int cs_dbs_update(struct cpufreq_policy *policy)
 
 	/* Check for frequency decrease */
 	if (load < cs_tuners->down_threshold) {
-		/*
-		 * if we cannot reduce the frequency anymore, break out early
-		 */
-		if (requested_freq == policy->min)
-			goto out;
-
-		if (requested_freq > freq_step)
+		if (requested_freq > policy->min + freq_step)
 			requested_freq -= freq_step;
 		else
 			requested_freq = policy->min;
-- 
2.31.1.272.g89b43f80a514

Re: [PATCH 1/3] cpufreq: Fix typo in comment

[zhenglifeng (A)]

On 5/21/2026 7:39 PM, Viresh Kumar wrote:
> Replace "diver" with "driver" in the comment describing
> CPUFREQ_NEED_UPDATE_LIMITS.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>  include/linux/cpufreq.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 2ab691828e48..4d4b4ed24b30 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -434,7 +434,7 @@ struct cpufreq_driver {
>  /*
>   * Set by drivers that need to update internal upper and lower boundaries along
>   * with the target frequency and so the core and governors should also invoke
> - * the diver if the target frequency does not change, but the policy min or max
> + * the driver if the target frequency does not change, but the policy min or max
>   * may have changed.
>   */
>  #define CPUFREQ_NEED_UPDATE_LIMITS		BIT(0)

For all three patches:

Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>

Thanks for always doing things so fast.

Re: [PATCH 1/3] cpufreq: Fix typo in comment

[Zhongqiu Han]

On 5/21/2026 7:39 PM, Viresh Kumar wrote:
> Replace "diver" with "driver" in the comment describing
> CPUFREQ_NEED_UPDATE_LIMITS.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>


Looks good to me.

Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>


> ---
>   include/linux/cpufreq.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 2ab691828e48..4d4b4ed24b30 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -434,7 +434,7 @@ struct cpufreq_driver {
>   /*
>    * Set by drivers that need to update internal upper and lower boundaries along
>    * with the target frequency and so the core and governors should also invoke
> - * the diver if the target frequency does not change, but the policy min or max
> + * the driver if the target frequency does not change, but the policy min or max
>    * may have changed.
>    */
>   #define CPUFREQ_NEED_UPDATE_LIMITS		BIT(0)


-- 
Thx and BRs,
Zhongqiu Han

Re: [PATCH 2/3] cpufreq: Avoid redundant target() calls for unchanged limits

[Zhongqiu Han]

On 5/21/2026 7:39 PM, Viresh Kumar wrote:
> Drivers setting CPUFREQ_NEED_UPDATE_LIMITS expect target() to be
> invoked even if the target frequency remains unchanged, so they can
> update their internal policy limits state.
> 
> Currently the core invokes target() unconditionally whenever the
> requested frequency matches policy->cur for such drivers, even if
> policy->min and policy->max haven't changed since the previous update.
> 
> Track pending policy limit updates explicitly and skip redundant
> target() invocations when neither the target frequency nor the
> effective limits changed.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>   drivers/cpufreq/cpufreq.c      | 31 ++++++++++++++++++++++---------
>   drivers/cpufreq/intel_pstate.c |  1 +
>   include/linux/cpufreq.h        |  3 +++
>   3 files changed, 26 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 44eb1b7e7fc1..225228e9f4ed 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2366,9 +2366,13 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
>   	 * exactly same freq is called again and so we can save on few function
>   	 * calls.
>   	 */
> -	if (target_freq == policy->cur &&
> -	    !(cpufreq_driver->flags & CPUFREQ_NEED_UPDATE_LIMITS))
> -		return 0;
> +	if (target_freq == policy->cur) {
> +		if (!(cpufreq_driver->flags & CPUFREQ_NEED_UPDATE_LIMITS) ||
> +		    !policy->update_limits)
> +			return 0;
> +
> +		policy->update_limits = false;
> +	}
>   
>   	if (cpufreq_driver->target) {
>   		/*
> @@ -2620,6 +2624,7 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
>   {
>   	struct cpufreq_policy_data new_data;
>   	struct cpufreq_governor *old_gov;
> +	unsigned int freq;
>   	int ret;
>   
>   	memcpy(&new_data.cpuinfo, &policy->cpuinfo, sizeof(policy->cpuinfo));
> @@ -2652,12 +2657,20 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
>   	 * compiler optimizations around them because they may be accessed
>   	 * concurrently by cpufreq_driver_resolve_freq() during the update.
>   	 */
> -	WRITE_ONCE(policy->max, __resolve_freq(policy, new_data.max,
> -					       new_data.min, new_data.max,
> -					       CPUFREQ_RELATION_H));
> -	new_data.min = __resolve_freq(policy, new_data.min, new_data.min,
> -				      new_data.max, CPUFREQ_RELATION_L);
> -	WRITE_ONCE(policy->min, new_data.min > policy->max ? policy->max : new_data.min);
> +	freq = __resolve_freq(policy, new_data.max, new_data.min, new_data.max,
> +			      CPUFREQ_RELATION_H);
> +	if (freq != policy->max) {
> +		WRITE_ONCE(policy->max, freq);
> +		policy->update_limits = true;
> +	}
> +
> +	freq = __resolve_freq(policy, new_data.min, new_data.min, new_data.max,
> +			      CPUFREQ_RELATION_L);
> +	freq = min(freq, policy->max);
> +	if (freq != policy->min) {
> +		WRITE_ONCE(policy->min, freq);
> +		policy->update_limits = true;
> +	}
>   
>   	trace_cpu_frequency_limits(policy);
>   
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 1292da53e5fc..7f19ec6b70ba 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -2942,6 +2942,7 @@ static void intel_pstate_adjust_policy_max(struct cpudata *cpu,
>   	    policy->max > cpu->pstate.max_freq) {
>   		pr_debug("policy->max > max non turbo frequency\n");
>   		policy->max = policy->cpuinfo.max_freq;
> +		policy->update_limits = true;


This patch looks good to me overall.

Just one concern:

Could this be redundant?

It seems that intel_pstate_adjust_policy_max() is only triggered when
!hwp_active, whereas CPUFREQ_NEED_UPDATE_LIMITS is set when
hwp_active is enabled. If so, the update_limits flag set here may not
actually be consumed, as __cpufreq_driver_target() would skip the
update_limits check for drivers without CPUFREQ_NEED_UPDATE_LIMITS.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/cpufreq/intel_pstate.c#n3808

Also, it looks like intel_pstate_adjust_policy_max() uses struct
cpufreq_policy_data rather than cpufreq_policy.


>   	}
>   }
>   
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 4d4b4ed24b30..ae9d1ce4f49c 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -146,6 +146,9 @@ struct cpufreq_policy {
>   	/* Per policy boost supported flag. */
>   	bool			boost_supported;
>   
> +	/* Pending policy->min/max update for the driver */
> +	bool			update_limits;
> +
>   	 /* Cached frequency lookup from cpufreq_driver_resolve_freq. */
>   	unsigned int cached_target_freq;
>   	unsigned int cached_resolved_idx;


-- 
Thx and BRs,
Zhongqiu Han

Re: [PATCH 1/3] cpufreq: Fix typo in comment

[Viresh Kumar]

On 21-05-26, 20:22, zhenglifeng (A) wrote:
> On 5/21/2026 7:39 PM, Viresh Kumar wrote:
> > Replace "diver" with "driver" in the comment describing
> > CPUFREQ_NEED_UPDATE_LIMITS.
> > 
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > ---
> >  include/linux/cpufreq.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> > index 2ab691828e48..4d4b4ed24b30 100644
> > --- a/include/linux/cpufreq.h
> > +++ b/include/linux/cpufreq.h
> > @@ -434,7 +434,7 @@ struct cpufreq_driver {
> >  /*
> >   * Set by drivers that need to update internal upper and lower boundaries along
> >   * with the target frequency and so the core and governors should also invoke
> > - * the diver if the target frequency does not change, but the policy min or max
> > + * the driver if the target frequency does not change, but the policy min or max
> >   * may have changed.
> >   */
> >  #define CPUFREQ_NEED_UPDATE_LIMITS		BIT(0)
> 
> For all three patches:
> 
> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
> 
> Thanks for always doing things so fast.

Thanks.

-- 
viresh

Re: [PATCH 2/3] cpufreq: Avoid redundant target() calls for unchanged limits

[Viresh Kumar]

On 21-05-26, 21:58, Zhongqiu Han wrote:
> > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> > index 1292da53e5fc..7f19ec6b70ba 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -2942,6 +2942,7 @@ static void intel_pstate_adjust_policy_max(struct cpudata *cpu,
> >   	    policy->max > cpu->pstate.max_freq) {
> >   		pr_debug("policy->max > max non turbo frequency\n");
> >   		policy->max = policy->cpuinfo.max_freq;
> > +		policy->update_limits = true;
> 
> 
> Could this be redundant?

Yeah, this won't even compile I think. In my first attempt I tried to
make the update_limits change from within verify in cpufreq.h and that
caused a build failure and then I moved to cpufreq_set_policy() and
forgot to fix this one. And my arm64 build didn't cover this file.
Sorry about that.

> It seems that intel_pstate_adjust_policy_max() is only triggered when
> !hwp_active, whereas CPUFREQ_NEED_UPDATE_LIMITS is set when
> hwp_active is enabled. If so, the update_limits flag set here may not
> actually be consumed, as __cpufreq_driver_target() would skip the
> update_limits check for drivers without CPUFREQ_NEED_UPDATE_LIMITS.

Good catch.

Rafael, is the understanding correct ? I can drop the intel_pstate
change in that case.

-- 
viresh

Re: [PATCH 2/3] cpufreq: Avoid redundant target() calls for unchanged limits

[Rafael J. Wysocki]

On Thu, May 21, 2026 at 4:33 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 21-05-26, 21:58, Zhongqiu Han wrote:
> > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> > > index 1292da53e5fc..7f19ec6b70ba 100644
> > > --- a/drivers/cpufreq/intel_pstate.c
> > > +++ b/drivers/cpufreq/intel_pstate.c
> > > @@ -2942,6 +2942,7 @@ static void intel_pstate_adjust_policy_max(struct cpudata *cpu,
> > >         policy->max > cpu->pstate.max_freq) {
> > >             pr_debug("policy->max > max non turbo frequency\n");
> > >             policy->max = policy->cpuinfo.max_freq;
> > > +           policy->update_limits = true;
> >
> >
> > Could this be redundant?
>
> Yeah, this won't even compile I think. In my first attempt I tried to
> make the update_limits change from within verify in cpufreq.h and that
> caused a build failure and then I moved to cpufreq_set_policy() and
> forgot to fix this one. And my arm64 build didn't cover this file.
> Sorry about that.
>
> > It seems that intel_pstate_adjust_policy_max() is only triggered when
> > !hwp_active, whereas CPUFREQ_NEED_UPDATE_LIMITS is set when
> > hwp_active is enabled. If so, the update_limits flag set here may not
> > actually be consumed, as __cpufreq_driver_target() would skip the
> > update_limits check for drivers without CPUFREQ_NEED_UPDATE_LIMITS.
>
> Good catch.
>
> Rafael, is the understanding correct ? I can drop the intel_pstate
> change in that case.

Yes, it is.  intel_pstate only sets CPUFREQ_NEED_UPDATE_LIMITS when
hwp_active is set, in which case intel_pstate_adjust_policy_max() is a
NOP.