[PATCH v5 0/6] cpufreq: Introduce boost frequency QoS

[PATCH v5 0/6] cpufreq: Introduce boost frequency QoS

[Pierre Gondois]

The Power Management Quality of Service (PM QoS) allows to
aggregate constraints from multiple entities. It is currently
used to manage the min/max frequency of a given policy.

Frequency constraints can come from:
- Thermal framework: acpi_thermal_cpufreq_init()
- Firmware: _PPC objects: acpi_processor_ppc_init()
- User: by setting policyX/scaling_[min|max]_freq
The minimum of the max frequency constraints is used to compute
the resulting maximum allowed frequency.

When enabling boost frequencies, the same frequency request object
(policy->max_freq_req) as to handle requests from users is used.
As a result, when setting:
- scaling_max_freq
- boost
The last sysfs file used overwrites the request from the other
sysfs file.

To avoid this:
1. Create a per-policy boost_freq_req to save the boost
constraints instead of overwriting the last scaling_max_freq
constraint.

2. policy_set_boost() calls the cpufreq set_boost callback.
Update the newly added boost_freq_req request from there:
- whenever boost is toggled
- to cover all possible paths

3. In the existing set_boost() callbacks:
- Don't update policy->max as this is done through the qos notifier
  cpufreq_notifier_max() which calls cpufreq_set_policy().
- Remove freq_qos_update_request() calls as the qos request is now
  done in policy_set_boost() and updates the new boost_freq_req

This patch-set additionally does:
- if a driver .init() callback sets policy->min and policy->max,
  these values are used are min/max_freq_req QoS constraints
- Remove policy->min and policy->max initialization in .init()
  callback if the value is identical to cpuinfo.min/max_freq
- RFC: allow decreasing cpuinfo.max_freq when using freq_table.

------------

E.g.:
On a Juno with available frequencies: 600.000, 1.000.000
Boost frequencies: 1.200.000
Using the cppc-cpufreq driver.

---
Without the patches:
# ## Init state
scaling_max_freq:1000000
cpuinfo_max_freq:1000000

# echo 700000 > scaling_max_freq
scaling_max_freq:700000
cpuinfo_max_freq:1000000

# echo 1 > ../boost
scaling_max_freq:1200000
cpuinfo_max_freq:1200000

# echo 800000 > scaling_max_freq
scaling_max_freq:800000
cpuinfo_max_freq:1200000

# echo 0 > ../boost
scaling_max_freq:1000000
cpuinfo_max_freq:1000000

---
With the patches:
# ## Init
scaling_max_freq:1000000
cpuinfo_max_freq:1000000

# echo 700000 > scaling_max_freq
scaling_max_freq:700000
cpuinfo_max_freq:1000000

# echo 1 > ../boost
scaling_max_freq:700000
cpuinfo_max_freq:1200000

# echo 800000 > scaling_max_freq
scaling_max_freq:800000
cpuinfo_max_freq:1200000

# echo 0 > ../boost
scaling_max_freq:800000
cpuinfo_max_freq:1000000

---

With the patches, the maximum scaling frequency requested is
conserved even though boosting is enabled/disabled.

---

v1: https://lore.kernel.org/all/20251204101344.192678-1-pierre.gondois@arm.com/#t
v2: https://lore.kernel.org/all/20251208105933.1369125-1-pierre.gondois@arm.com/#t
Changes:
- Fixed error path
- Integrated [PATCH 1/4] Revert "cpufreq: Fix re-boost issue after hotplugging a CPU"
  to another patch
v3:
Changes:
- Fixed error path
- Extracted the revert of:
  "cpufreq: Fix re-boost issue after hotplugging a CPU"
  for clarity purpose
- Set cpuinfo.max_freq as a max_freq_req QoS constraint by default
New patches:
- "cpufreq: Allow decreasing cpuinfo.max_freq"
- "cpufreq: Set policy->min and max as QoS constraints"
v4:
- Correct reported issues
v5:
- Corrections

Pierre Gondois (6):
  cpufreq: Remove per-CPU QoS constraint
  cpufreq: Add boost_freq_req QoS request
  cpufreq: Centralize boost freq QoS requests
  cpufreq: Update .set_boost() callbacks to rely on boost_freq_req
  cpufreq: Set policy->min and max as real QoS constraints
  cpufreq/freq_table: Allow decreasing cpuinfo.max_freq

 drivers/cpufreq/acpi-cpufreq.c    |  1 +
 drivers/cpufreq/amd-pstate.c      | 26 +++++-----
 drivers/cpufreq/cppc_cpufreq.c    | 10 +---
 drivers/cpufreq/cpufreq-nforce2.c |  4 +-
 drivers/cpufreq/cpufreq.c         | 84 +++++++++++++++++++++++--------
 drivers/cpufreq/freq_table.c      | 14 ++----
 drivers/cpufreq/gx-suspmod.c      |  9 ++--
 drivers/cpufreq/intel_pstate.c    |  3 --
 drivers/cpufreq/pcc-cpufreq.c     |  8 +--
 drivers/cpufreq/pxa3xx-cpufreq.c  |  4 +-
 drivers/cpufreq/virtual-cpufreq.c |  5 +-
 include/linux/cpufreq.h           |  1 +
 12 files changed, 96 insertions(+), 73 deletions(-)

--
2.43.0

[PATCH v5 1/6] cpufreq: Remove per-CPU QoS constraint

[Pierre Gondois]

policy->max_freq_req represents the maximum allowed frequency as
requested by the policyX/scaling_max_freq sysfs file. This request
applies to all CPUs of the policy. It is not possible to request
a per-CPU maximum frequency.

Thus, the interaction between the policy boost and scaling_max_freq
settings should be handled by adding a boost specific QoS constraint.
This will be handled in the following patches.

This patch reverts of:
commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
a CPU")

Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
---
 drivers/cpufreq/cpufreq.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 4472bb1ec83c7..db414c052658b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1481,10 +1481,6 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
 
 		blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
 				CPUFREQ_CREATE_POLICY, policy);
-	} else {
-		ret = freq_qos_update_request(policy->max_freq_req, policy->max);
-		if (ret < 0)
-			goto out_destroy_policy;
 	}
 
 	if (cpufreq_driver->get && has_target()) {
-- 
2.43.0

[PATCH v5 2/6] cpufreq: Add boost_freq_req QoS request

[Pierre Gondois]

The Power Management Quality of Service (PM QoS) allows to
aggregate constraints from multiple entities. It is currently
used to manage the min/max frequency of a given policy.

Frequency constraints can come for instance from:
- Thermal framework: acpi_thermal_cpufreq_init()
- Firmware: _PPC objects: acpi_processor_ppc_init()
- User: by setting policyX/scaling_[min|max]_freq
The minimum of the max frequency constraints is used to compute
the resulting maximum allowed frequency.

When enabling boost frequencies, the same frequency request object
(policy->max_freq_req) as to handle requests from users is used.
As a result, when setting:
- scaling_max_freq
- boost
The last sysfs file used overwrites the request from the other
sysfs file.

To avoid this, create a per-policy boost_freq_req to save the boost
constraints instead of overwriting the last scaling_max_freq
constraint.

Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
---
 drivers/cpufreq/cpufreq.c | 37 ++++++++++++++++++++++++++++++++-----
 include/linux/cpufreq.h   |  1 +
 2 files changed, 33 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index db414c052658b..50467b938668a 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1359,17 +1359,21 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
 	/* Cancel any pending policy->update work before freeing the policy. */
 	cancel_work_sync(&policy->update);
 
-	if (policy->max_freq_req) {
+	if ((policy->max_freq_req && !policy->boost_supported) ||
+	    policy->boost_freq_req) {
 		/*
-		 * Remove max_freq_req after sending CPUFREQ_REMOVE_POLICY
-		 * notification, since CPUFREQ_CREATE_POLICY notification was
-		 * sent after adding max_freq_req earlier.
+		 * Remove max/boost _freq_req after sending CPUFREQ_REMOVE_POLICY
+		 * notification, since CPUFREQ_CREATE_POLICY notification was sent
+		 * after adding max/boost _freq_req earlier.
 		 */
 		blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
 					     CPUFREQ_REMOVE_POLICY, policy);
-		freq_qos_remove_request(policy->max_freq_req);
 	}
 
+	freq_qos_remove_request(policy->boost_freq_req);
+	kfree(policy->boost_freq_req);
+
+	freq_qos_remove_request(policy->max_freq_req);
 	freq_qos_remove_request(policy->min_freq_req);
 	kfree(policy->min_freq_req);
 
@@ -1479,6 +1483,29 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
 			goto out_destroy_policy;
 		}
 
+		if (policy->boost_supported) {
+			policy->boost_freq_req = kzalloc(sizeof(*policy->boost_freq_req),
+							 GFP_KERNEL);
+			if (!policy->boost_freq_req) {
+				ret = -ENOMEM;
+				goto out_destroy_policy;
+			}
+
+			ret = freq_qos_add_request(&policy->constraints,
+						   policy->boost_freq_req,
+						   FREQ_QOS_MAX,
+						   FREQ_QOS_MAX_DEFAULT_VALUE);
+			if (ret < 0) {
+				/*
+				 * So we don't call freq_qos_remove_request() for an
+				 * uninitialized request.
+				 */
+				kfree(policy->boost_freq_req);
+				policy->boost_freq_req = NULL;
+				goto out_destroy_policy;
+			}
+		}
+
 		blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
 				CPUFREQ_CREATE_POLICY, policy);
 	}
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 0465d1e6f72ac..c292a6a19e4f5 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -81,6 +81,7 @@ struct cpufreq_policy {
 	struct freq_constraints	constraints;
 	struct freq_qos_request	*min_freq_req;
 	struct freq_qos_request	*max_freq_req;
+	struct freq_qos_request *boost_freq_req;
 
 	struct cpufreq_frequency_table	*freq_table;
 	enum cpufreq_table_sorting freq_table_sorted;
-- 
2.43.0

[PATCH v5 3/6] cpufreq: Centralize boost freq QoS requests

[Pierre Gondois]

policy_set_boost() calls the cpufreq set_boost callback.
Update the newly added boost_freq_req request from there:
- whenever boost is toggled
- to cover all possible paths

Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
---
 drivers/cpufreq/cpufreq.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 50467b938668a..42de32488f422 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -603,10 +603,19 @@ static int policy_set_boost(struct cpufreq_policy *policy, bool enable)
 	policy->boost_enabled = enable;
 
 	ret = cpufreq_driver->set_boost(policy, enable);
-	if (ret)
+	if (ret) {
 		policy->boost_enabled = !policy->boost_enabled;
+		return ret;
+	}
 
-	return ret;
+	ret = freq_qos_update_request(policy->boost_freq_req, policy->cpuinfo.max_freq);
+	if (ret < 0) {
+		policy->boost_enabled = !policy->boost_enabled;
+		cpufreq_driver->set_boost(policy, policy->boost_enabled);
+		return ret;
+	}
+
+	return 0;
 }
 
 static ssize_t store_local_boost(struct cpufreq_policy *policy,
-- 
2.43.0

[PATCH v5 4/6] cpufreq: Update .set_boost() callbacks to rely on boost_freq_req

[Pierre Gondois]

In the existing .set_boost() callbacks:
- Don't update policy->max as this is done through the qos notifier
  cpufreq_notifier_max() which calls cpufreq_set_policy().
- Remove freq_qos_update_request() calls as the qos request is now
  done in policy_set_boost() and updates the new boost_freq_req

Note:
cpufreq_frequency_table_cpuinfo() is also called through:
cpufreq_policy_online()
\-cpufreq_table_validate_and_sort()
  \-cpufreq_frequency_table_cpuinfo()
which relies on cpufreq_frequency_table_cpuinfo() to set
policy->min and max initizalization at driver init. This
regression is solved in the next patch.

Note2:
acpi-cpufreq.c seems to be the only cpufreq driver not
setting cpuinfo.max_freq. Populate it the nominal frequency at
driver init.

Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
---
 drivers/cpufreq/acpi-cpufreq.c |  1 +
 drivers/cpufreq/amd-pstate.c   |  2 --
 drivers/cpufreq/cppc_cpufreq.c | 10 ++--------
 drivers/cpufreq/cpufreq.c      | 16 +++++++---------
 drivers/cpufreq/freq_table.c   |  7 +++----
 5 files changed, 13 insertions(+), 23 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index e73a66785d69d..6a6e26e1be14a 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -857,6 +857,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
 		 * governor from selecting inadequate CPU frequencies.
 		 */
 		arch_set_max_freq_ratio(true);
+		policy->cpuinfo.max_freq = nominal_freq;
 	}
 
 	policy->freq_table = freq_table;
diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index c45bc98721d24..310d5938cbdf6 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -756,8 +756,6 @@ static int amd_pstate_cpu_boost_update(struct cpufreq_policy *policy, bool on)
 	else if (policy->cpuinfo.max_freq > nominal_freq)
 		policy->cpuinfo.max_freq = nominal_freq;
 
-	policy->max = policy->cpuinfo.max_freq;
-
 	if (cppc_state == AMD_PSTATE_PASSIVE) {
 		ret = freq_qos_update_request(&cpudata->req[1], policy->cpuinfo.max_freq);
 		if (ret < 0)
diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
index 9eac77c4f2944..4c46c7ea318eb 100644
--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -775,17 +775,11 @@ static int cppc_cpufreq_set_boost(struct cpufreq_policy *policy, int state)
 {
 	struct cppc_cpudata *cpu_data = policy->driver_data;
 	struct cppc_perf_caps *caps = &cpu_data->perf_caps;
-	int ret;
 
 	if (state)
-		policy->max = cppc_perf_to_khz(caps, caps->highest_perf);
+		policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->highest_perf);
 	else
-		policy->max = cppc_perf_to_khz(caps, caps->nominal_perf);
-	policy->cpuinfo.max_freq = policy->max;
-
-	ret = freq_qos_update_request(policy->max_freq_req, policy->max);
-	if (ret < 0)
-		return ret;
+		policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->nominal_perf);
 
 	return 0;
 }
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 42de32488f422..20266fb42d18d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1500,10 +1500,14 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
 				goto out_destroy_policy;
 			}
 
+			/*
+			 * If boost is supported,
+			 * init the constraint with cpuinfo.max_freq.
+			 */
 			ret = freq_qos_add_request(&policy->constraints,
 						   policy->boost_freq_req,
 						   FREQ_QOS_MAX,
-						   FREQ_QOS_MAX_DEFAULT_VALUE);
+						   policy->cpuinfo.max_freq);
 			if (ret < 0) {
 				/*
 				 * So we don't call freq_qos_remove_request() for an
@@ -2818,16 +2822,10 @@ int cpufreq_boost_set_sw(struct cpufreq_policy *policy, int state)
 		return -ENXIO;
 
 	ret = cpufreq_frequency_table_cpuinfo(policy);
-	if (ret) {
+	if (ret)
 		pr_err("%s: Policy frequency update failed\n", __func__);
-		return ret;
-	}
 
-	ret = freq_qos_update_request(policy->max_freq_req, policy->max);
-	if (ret < 0)
-		return ret;
-
-	return 0;
+	return ret;
 }
 EXPORT_SYMBOL_GPL(cpufreq_boost_set_sw);
 
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index 7f251daf03ce3..9b37f37c36389 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -49,16 +49,15 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy)
 			max_freq = freq;
 	}
 
-	policy->min = policy->cpuinfo.min_freq = min_freq;
-	policy->max = max_freq;
+	policy->cpuinfo.min_freq = min_freq;
 	/*
 	 * If the driver has set its own cpuinfo.max_freq above max_freq, leave
 	 * it as is.
 	 */
 	if (policy->cpuinfo.max_freq < max_freq)
-		policy->max = policy->cpuinfo.max_freq = max_freq;
+		policy->cpuinfo.max_freq = max_freq;
 
-	if (policy->min == ~0)
+	if (min_freq == ~0)
 		return -EINVAL;
 	else
 		return 0;
-- 
2.43.0

[PATCH v5 5/6] cpufreq: Set policy->min and max as real QoS constraints

[Pierre Gondois]

cpufreq_set_policy() will ultimately override the policy min/max
values written in the .init() callback through:
cpufreq_policy_online()
\-cpufreq_init_policy()
  \-cpufreq_set_policy()
    \-/* Set policy->min/max */
Thus the policy min/max values provided are only temporary.

There is an exception if CPUFREQ_NEED_INITIAL_FREQ_CHECK is set and:
cpufreq_policy_online()
\-cpufreq_init_policy()
  \-__cpufreq_driver_target()
    \-cpufreq_driver->target()
is called. In this case, some drivers use the policy min/max
values in their .target() callback before they are overridden.

Check cpufreq drivers:
- if their .target() callback doesn't use policy->min or max,
  remove the initialization
- assuming policy->min or max values were populated as constraints,
  set them as QoS real constraints in cpufreq_policy_online()

Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
---
 drivers/cpufreq/amd-pstate.c      | 24 ++++++++++++------------
 drivers/cpufreq/cpufreq-nforce2.c |  4 ++--
 drivers/cpufreq/cpufreq.c         | 16 ++++++++++++++--
 drivers/cpufreq/gx-suspmod.c      |  9 ++++-----
 drivers/cpufreq/intel_pstate.c    |  3 ---
 drivers/cpufreq/pcc-cpufreq.c     |  8 ++++----
 drivers/cpufreq/pxa3xx-cpufreq.c  |  4 ++--
 drivers/cpufreq/virtual-cpufreq.c |  5 +----
 8 files changed, 39 insertions(+), 34 deletions(-)

diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index 310d5938cbdf6..aaafbe9b26cae 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -1003,12 +1003,12 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
 
 	perf = READ_ONCE(cpudata->perf);
 
-	policy->cpuinfo.min_freq = policy->min = perf_to_freq(perf,
-							      cpudata->nominal_freq,
-							      perf.lowest_perf);
-	policy->cpuinfo.max_freq = policy->max = perf_to_freq(perf,
-							      cpudata->nominal_freq,
-							      perf.highest_perf);
+	policy->cpuinfo.min_freq = perf_to_freq(perf,
+						cpudata->nominal_freq,
+						perf.lowest_perf);
+	policy->cpuinfo.max_freq = perf_to_freq(perf,
+						cpudata->nominal_freq,
+						perf.highest_perf);
 
 	ret = amd_pstate_cppc_enable(policy);
 	if (ret)
@@ -1485,12 +1485,12 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
 
 	perf = READ_ONCE(cpudata->perf);
 
-	policy->cpuinfo.min_freq = policy->min = perf_to_freq(perf,
-							      cpudata->nominal_freq,
-							      perf.lowest_perf);
-	policy->cpuinfo.max_freq = policy->max = perf_to_freq(perf,
-							      cpudata->nominal_freq,
-							      perf.highest_perf);
+	policy->cpuinfo.min_freq = perf_to_freq(perf,
+						cpudata->nominal_freq,
+						perf.lowest_perf);
+	policy->cpuinfo.max_freq = perf_to_freq(perf,
+						cpudata->nominal_freq,
+						perf.highest_perf);
 	policy->driver_data = cpudata;
 
 	ret = amd_pstate_cppc_enable(policy);
diff --git a/drivers/cpufreq/cpufreq-nforce2.c b/drivers/cpufreq/cpufreq-nforce2.c
index fbbbe501cf2dc..831102522ad64 100644
--- a/drivers/cpufreq/cpufreq-nforce2.c
+++ b/drivers/cpufreq/cpufreq-nforce2.c
@@ -355,8 +355,8 @@ static int nforce2_cpu_init(struct cpufreq_policy *policy)
 		min_fsb = NFORCE2_MIN_FSB;
 
 	/* cpuinfo and default policy values */
-	policy->min = policy->cpuinfo.min_freq = min_fsb * fid * 100;
-	policy->max = policy->cpuinfo.max_freq = max_fsb * fid * 100;
+	policy->cpuinfo.min_freq = min_fsb * fid * 100;
+	policy->cpuinfo.max_freq = max_fsb * fid * 100;
 
 	return 0;
 }
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 20266fb42d18d..a855a77a5fa22 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1452,6 +1452,18 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
 	cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
 
 	if (new_policy) {
+		unsigned int min, max;
+
+		/*
+		 * If the driver has set policy->min or max,
+		 * use the value as a QoS request.
+		 */
+		min = max(FREQ_QOS_MIN_DEFAULT_VALUE, policy->min);
+		if (policy->max)
+			max = min(FREQ_QOS_MAX_DEFAULT_VALUE, policy->max);
+		else
+			max = FREQ_QOS_MAX_DEFAULT_VALUE;
+
 		for_each_cpu(j, policy->related_cpus) {
 			per_cpu(cpufreq_cpu_data, j) = policy;
 			add_cpu_dev_symlink(policy, j, get_cpu_device(j));
@@ -1466,7 +1478,7 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
 
 		ret = freq_qos_add_request(&policy->constraints,
 					   policy->min_freq_req, FREQ_QOS_MIN,
-					   FREQ_QOS_MIN_DEFAULT_VALUE);
+					   min);
 		if (ret < 0) {
 			/*
 			 * So we don't call freq_qos_remove_request() for an
@@ -1486,7 +1498,7 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
 
 		ret = freq_qos_add_request(&policy->constraints,
 					   policy->max_freq_req, FREQ_QOS_MAX,
-					   FREQ_QOS_MAX_DEFAULT_VALUE);
+					   max);
 		if (ret < 0) {
 			policy->max_freq_req = NULL;
 			goto out_destroy_policy;
diff --git a/drivers/cpufreq/gx-suspmod.c b/drivers/cpufreq/gx-suspmod.c
index 75b3ef7ec6796..57999b8d51fa2 100644
--- a/drivers/cpufreq/gx-suspmod.c
+++ b/drivers/cpufreq/gx-suspmod.c
@@ -397,7 +397,7 @@ static int cpufreq_gx_target(struct cpufreq_policy *policy,
 
 static int cpufreq_gx_cpu_init(struct cpufreq_policy *policy)
 {
-	unsigned int maxfreq;
+	unsigned int minfreq, maxfreq;
 
 	if (!policy || policy->cpu != 0)
 		return -ENODEV;
@@ -418,11 +418,10 @@ static int cpufreq_gx_cpu_init(struct cpufreq_policy *policy)
 	policy->cpu = 0;
 
 	if (max_duration < POLICY_MIN_DIV)
-		policy->min = maxfreq / max_duration;
+		minfreq = maxfreq / max_duration;
 	else
-		policy->min = maxfreq / POLICY_MIN_DIV;
-	policy->max = maxfreq;
-	policy->cpuinfo.min_freq = maxfreq / max_duration;
+		minfreq = maxfreq / POLICY_MIN_DIV;
+	policy->cpuinfo.min_freq = minfreq;
 	policy->cpuinfo.max_freq = maxfreq;
 
 	return 0;
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index ec4abe3745736..bf2f7524d04a9 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -3047,9 +3047,6 @@ static int __intel_pstate_cpu_init(struct cpufreq_policy *policy)
 	policy->cpuinfo.max_freq = READ_ONCE(global.no_turbo) ?
 			cpu->pstate.max_freq : cpu->pstate.turbo_freq;
 
-	policy->min = policy->cpuinfo.min_freq;
-	policy->max = policy->cpuinfo.max_freq;
-
 	intel_pstate_init_acpi_perf_limits(policy);
 
 	policy->fast_switch_possible = true;
diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
index ac2e90a65f0c4..231edfe8cabaa 100644
--- a/drivers/cpufreq/pcc-cpufreq.c
+++ b/drivers/cpufreq/pcc-cpufreq.c
@@ -551,13 +551,13 @@ static int pcc_cpufreq_cpu_init(struct cpufreq_policy *policy)
 		goto out;
 	}
 
-	policy->max = policy->cpuinfo.max_freq =
+	policy->cpuinfo.max_freq =
 		ioread32(&pcch_hdr->nominal) * 1000;
-	policy->min = policy->cpuinfo.min_freq =
+	policy->cpuinfo.min_freq =
 		ioread32(&pcch_hdr->minimum_frequency) * 1000;
 
-	pr_debug("init: policy->max is %d, policy->min is %d\n",
-		policy->max, policy->min);
+	pr_debug("init: max_freq is %d, min_freq is %d\n",
+		 policy->cpuinfo.max_freq, policy->cpuinfo.min_freq);
 out:
 	return result;
 }
diff --git a/drivers/cpufreq/pxa3xx-cpufreq.c b/drivers/cpufreq/pxa3xx-cpufreq.c
index 4afa48d172dbe..f53b9d7edc76a 100644
--- a/drivers/cpufreq/pxa3xx-cpufreq.c
+++ b/drivers/cpufreq/pxa3xx-cpufreq.c
@@ -185,8 +185,8 @@ static int pxa3xx_cpufreq_init(struct cpufreq_policy *policy)
 	int ret = -EINVAL;
 
 	/* set default policy and cpuinfo */
-	policy->min = policy->cpuinfo.min_freq = 104000;
-	policy->max = policy->cpuinfo.max_freq =
+	policy->cpuinfo.min_freq = 104000;
+	policy->cpuinfo.max_freq =
 		(cpu_is_pxa320()) ? 806000 : 624000;
 	policy->cpuinfo.transition_latency = 1000; /* FIXME: 1 ms, assumed */
 
diff --git a/drivers/cpufreq/virtual-cpufreq.c b/drivers/cpufreq/virtual-cpufreq.c
index 6ffa16d239b2b..60707bf6ce1e3 100644
--- a/drivers/cpufreq/virtual-cpufreq.c
+++ b/drivers/cpufreq/virtual-cpufreq.c
@@ -164,10 +164,7 @@ static int virt_cpufreq_get_freq_info(struct cpufreq_policy *policy)
 		policy->cpuinfo.min_freq = 1;
 		policy->cpuinfo.max_freq = virt_cpufreq_get_perftbl_entry(policy->cpu, 0);
 
-		policy->min = policy->cpuinfo.min_freq;
-		policy->max = policy->cpuinfo.max_freq;
-
-		policy->cur = policy->max;
+		policy->cur = policy->cpuinfo.max_freq;
 		return 0;
 	}
 
-- 
2.43.0

[RFC PATCH v5 6/6] cpufreq/freq_table: Allow decreasing cpuinfo.max_freq

[Pierre Gondois]

Drivers not using freq. tables update cpuinfo.max_freq in their
.set_boost() callback. E.g. amd-pstate, cppc_cpufreq.
Drivers relying on freq. tables and supporting boost frequencies
rely on cpufreq_frequency_table_cpuinfo(). cpuinfo.max_freq is
only updated if the new maximal value is higher than the previous
one.

Using the scmi-cpufreq driver which relies on freq. tables, enabling
boost will permanently increases the cpuinfo.max_freq value.
This patch allows to lower cpuinfo.max_freq.

Note:
commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly
if max boost is known")
favored having cpuinfo.max_freq reporting the maximal boosted
frequency of a CPU instead of the maximal reachable frequency
due to regressions in the frequency reported by cpuinfo.max
and scaling_cur_freq.
As stated above, this is not what most of the other cpufreq driver
do. I assume that the following patch:
commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to
cover boost frequencies")
was correct, but might not have tagged the boosted frequency with
the CPUFREQ_BOOST_FREQ flag in the freq. table.

Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
---
 drivers/cpufreq/freq_table.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index 9b37f37c36389..bd08cbe9e9ba3 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -50,12 +50,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy)
 	}

 	policy->cpuinfo.min_freq = min_freq;
-	/*
-	 * If the driver has set its own cpuinfo.max_freq above max_freq, leave
-	 * it as is.
-	 */
-	if (policy->cpuinfo.max_freq < max_freq)
-		policy->cpuinfo.max_freq = max_freq;
+	policy->cpuinfo.max_freq = max_freq;

 	if (min_freq == ~0)
 		return -EINVAL;
--
2.43.0

Re: [PATCH v5 2/6] cpufreq: Add boost_freq_req QoS request

[Rafael J. Wysocki]

On Wed, Feb 25, 2026 at 9:49 AM Pierre Gondois <pierre.gondois@arm.com> wrote:
>
> The Power Management Quality of Service (PM QoS) allows to
> aggregate constraints from multiple entities. It is currently
> used to manage the min/max frequency of a given policy.
>
> Frequency constraints can come for instance from:
> - Thermal framework: acpi_thermal_cpufreq_init()
> - Firmware: _PPC objects: acpi_processor_ppc_init()
> - User: by setting policyX/scaling_[min|max]_freq
> The minimum of the max frequency constraints is used to compute
> the resulting maximum allowed frequency.
>
> When enabling boost frequencies, the same frequency request object
> (policy->max_freq_req) as to handle requests from users is used.
> As a result, when setting:
> - scaling_max_freq
> - boost
> The last sysfs file used overwrites the request from the other
> sysfs file.
>
> To avoid this, create a per-policy boost_freq_req to save the boost
> constraints instead of overwriting the last scaling_max_freq
> constraint.
>
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> ---
>  drivers/cpufreq/cpufreq.c | 37 ++++++++++++++++++++++++++++++++-----
>  include/linux/cpufreq.h   |  1 +
>  2 files changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index db414c052658b..50467b938668a 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1359,17 +1359,21 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
>         /* Cancel any pending policy->update work before freeing the policy. */
>         cancel_work_sync(&policy->update);
>
> -       if (policy->max_freq_req) {
> +       if ((policy->max_freq_req && !policy->boost_supported) ||
> +           policy->boost_freq_req) {

Are you sure?

>                 /*
> -                * Remove max_freq_req after sending CPUFREQ_REMOVE_POLICY
> -                * notification, since CPUFREQ_CREATE_POLICY notification was
> -                * sent after adding max_freq_req earlier.
> +                * Remove max/boost _freq_req after sending CPUFREQ_REMOVE_POLICY
> +                * notification, since CPUFREQ_CREATE_POLICY notification was sent
> +                * after adding max/boost _freq_req earlier.
>                  */
>                 blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
>                                              CPUFREQ_REMOVE_POLICY, policy);
> -               freq_qos_remove_request(policy->max_freq_req);
>         }
>
> +       freq_qos_remove_request(policy->boost_freq_req);
> +       kfree(policy->boost_freq_req);
> +
> +       freq_qos_remove_request(policy->max_freq_req);
>         freq_qos_remove_request(policy->min_freq_req);
>         kfree(policy->min_freq_req);
>
> @@ -1479,6 +1483,29 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
>                         goto out_destroy_policy;
>                 }
>
> +               if (policy->boost_supported) {
> +                       policy->boost_freq_req = kzalloc(sizeof(*policy->boost_freq_req),
> +                                                        GFP_KERNEL);

Instead of doing this, why don't you add 1 to the policy->min_freq_req
allocation size when boost is supported?  You'll destroy the policy if
the allocation fails anyway.

> +                       if (!policy->boost_freq_req) {
> +                               ret = -ENOMEM;
> +                               goto out_destroy_policy;
> +                       }
> +
> +                       ret = freq_qos_add_request(&policy->constraints,
> +                                                  policy->boost_freq_req,
> +                                                  FREQ_QOS_MAX,
> +                                                  FREQ_QOS_MAX_DEFAULT_VALUE);
> +                       if (ret < 0) {
> +                               /*
> +                                * So we don't call freq_qos_remove_request() for an
> +                                * uninitialized request.
> +                                */
> +                               kfree(policy->boost_freq_req);
> +                               policy->boost_freq_req = NULL;
> +                               goto out_destroy_policy;
> +                       }
> +               }

Then you can put this block before the policy->min_freq_req addition
and the corresponding update of cpufreq_policy_free() will be more
straightforward.

BTW, if I'm not mistaken, there is a bug in the current
cpufreq_policy_free() because it may attempt to remove a NULL freq QoS
request for policy->min_freq_req.  I'll send a patch for that later if
I can confirm it.

> +
>                 blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
>                                 CPUFREQ_CREATE_POLICY, policy);
>         }
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 0465d1e6f72ac..c292a6a19e4f5 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -81,6 +81,7 @@ struct cpufreq_policy {
>         struct freq_constraints constraints;
>         struct freq_qos_request *min_freq_req;
>         struct freq_qos_request *max_freq_req;
> +       struct freq_qos_request *boost_freq_req;
>
>         struct cpufreq_frequency_table  *freq_table;
>         enum cpufreq_table_sorting freq_table_sorted;
> --

Re: [PATCH v5 2/6] cpufreq: Add boost_freq_req QoS request

[Rafael J. Wysocki]

On Wed, Mar 11, 2026 at 2:52 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Wed, Feb 25, 2026 at 9:49 AM Pierre Gondois <pierre.gondois@arm.com> wrote:
> >
> > The Power Management Quality of Service (PM QoS) allows to
> > aggregate constraints from multiple entities. It is currently
> > used to manage the min/max frequency of a given policy.
> >
> > Frequency constraints can come for instance from:
> > - Thermal framework: acpi_thermal_cpufreq_init()
> > - Firmware: _PPC objects: acpi_processor_ppc_init()
> > - User: by setting policyX/scaling_[min|max]_freq
> > The minimum of the max frequency constraints is used to compute
> > the resulting maximum allowed frequency.
> >
> > When enabling boost frequencies, the same frequency request object
> > (policy->max_freq_req) as to handle requests from users is used.
> > As a result, when setting:
> > - scaling_max_freq
> > - boost
> > The last sysfs file used overwrites the request from the other
> > sysfs file.
> >
> > To avoid this, create a per-policy boost_freq_req to save the boost
> > constraints instead of overwriting the last scaling_max_freq
> > constraint.
> >
> > Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> > ---
> >  drivers/cpufreq/cpufreq.c | 37 ++++++++++++++++++++++++++++++++-----
> >  include/linux/cpufreq.h   |  1 +
> >  2 files changed, 33 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index db414c052658b..50467b938668a 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -1359,17 +1359,21 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
> >         /* Cancel any pending policy->update work before freeing the policy. */
> >         cancel_work_sync(&policy->update);
> >
> > -       if (policy->max_freq_req) {
> > +       if ((policy->max_freq_req && !policy->boost_supported) ||
> > +           policy->boost_freq_req) {
>
> Are you sure?
>
> >                 /*
> > -                * Remove max_freq_req after sending CPUFREQ_REMOVE_POLICY
> > -                * notification, since CPUFREQ_CREATE_POLICY notification was
> > -                * sent after adding max_freq_req earlier.
> > +                * Remove max/boost _freq_req after sending CPUFREQ_REMOVE_POLICY
> > +                * notification, since CPUFREQ_CREATE_POLICY notification was sent
> > +                * after adding max/boost _freq_req earlier.
> >                  */
> >                 blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> >                                              CPUFREQ_REMOVE_POLICY, policy);
> > -               freq_qos_remove_request(policy->max_freq_req);
> >         }
> >
> > +       freq_qos_remove_request(policy->boost_freq_req);
> > +       kfree(policy->boost_freq_req);
> > +
> > +       freq_qos_remove_request(policy->max_freq_req);
> >         freq_qos_remove_request(policy->min_freq_req);
> >         kfree(policy->min_freq_req);
> >
> > @@ -1479,6 +1483,29 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
> >                         goto out_destroy_policy;
> >                 }
> >
> > +               if (policy->boost_supported) {
> > +                       policy->boost_freq_req = kzalloc(sizeof(*policy->boost_freq_req),
> > +                                                        GFP_KERNEL);
>
> Instead of doing this, why don't you add 1 to the policy->min_freq_req
> allocation size when boost is supported?  You'll destroy the policy if
> the allocation fails anyway.
>
> > +                       if (!policy->boost_freq_req) {
> > +                               ret = -ENOMEM;
> > +                               goto out_destroy_policy;
> > +                       }
> > +
> > +                       ret = freq_qos_add_request(&policy->constraints,
> > +                                                  policy->boost_freq_req,
> > +                                                  FREQ_QOS_MAX,
> > +                                                  FREQ_QOS_MAX_DEFAULT_VALUE);
> > +                       if (ret < 0) {
> > +                               /*
> > +                                * So we don't call freq_qos_remove_request() for an
> > +                                * uninitialized request.
> > +                                */
> > +                               kfree(policy->boost_freq_req);
> > +                               policy->boost_freq_req = NULL;
> > +                               goto out_destroy_policy;
> > +                       }
> > +               }
>
> Then you can put this block before the policy->min_freq_req addition
> and the corresponding update of cpufreq_policy_free() will be more
> straightforward.
>
> BTW, if I'm not mistaken, there is a bug in the current
> cpufreq_policy_free() because it may attempt to remove a NULL freq QoS
> request for policy->min_freq_req.  I'll send a patch for that later if
> I can confirm it.

Fortunately, freq_qos_remove_request() checks its argument against
NULL, never mind.

Of course, this means that
freq_qos_remove_request(policy->max_freq_req) need not be there under
the if (policy->max_freq_req) in cpufreq_policy_free() which you have
noticed.

Re: [PATCH v5 3/6] cpufreq: Centralize boost freq QoS requests

[Rafael J. Wysocki]

On Wed, Feb 25, 2026 at 9:50 AM Pierre Gondois <pierre.gondois@arm.com> wrote:
>
> policy_set_boost() calls the cpufreq set_boost callback.
> Update the newly added boost_freq_req request from there:
> - whenever boost is toggled
> - to cover all possible paths
>
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>

I don't quite see a reason for splitting this patch off the previous
one.  Can you combine them into one, please?

> ---
>  drivers/cpufreq/cpufreq.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 50467b938668a..42de32488f422 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -603,10 +603,19 @@ static int policy_set_boost(struct cpufreq_policy *policy, bool enable)
>         policy->boost_enabled = enable;
>
>         ret = cpufreq_driver->set_boost(policy, enable);
> -       if (ret)
> +       if (ret) {
>                 policy->boost_enabled = !policy->boost_enabled;
> +               return ret;
> +       }
>
> -       return ret;
> +       ret = freq_qos_update_request(policy->boost_freq_req, policy->cpuinfo.max_freq);
> +       if (ret < 0) {
> +               policy->boost_enabled = !policy->boost_enabled;
> +               cpufreq_driver->set_boost(policy, policy->boost_enabled);
> +               return ret;
> +       }
> +
> +       return 0;
>  }
>
>  static ssize_t store_local_boost(struct cpufreq_policy *policy,
> --
> 2.43.0
>

Re: [PATCH v5 4/6] cpufreq: Update .set_boost() callbacks to rely on boost_freq_req

[Rafael J. Wysocki]

On Wed, Feb 25, 2026 at 9:50 AM Pierre Gondois <pierre.gondois@arm.com> wrote:
>
> In the existing .set_boost() callbacks:
> - Don't update policy->max as this is done through the qos notifier
>   cpufreq_notifier_max() which calls cpufreq_set_policy().
> - Remove freq_qos_update_request() calls as the qos request is now
>   done in policy_set_boost() and updates the new boost_freq_req
>
> Note:
> cpufreq_frequency_table_cpuinfo() is also called through:
> cpufreq_policy_online()
> \-cpufreq_table_validate_and_sort()
>   \-cpufreq_frequency_table_cpuinfo()
> which relies on cpufreq_frequency_table_cpuinfo() to set
> policy->min and max initizalization at driver init. This
> regression is solved in the next patch.
>
> Note2:
> acpi-cpufreq.c seems to be the only cpufreq driver not
> setting cpuinfo.max_freq. Populate it the nominal frequency at
> driver init.
>
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> ---
>  drivers/cpufreq/acpi-cpufreq.c |  1 +
>  drivers/cpufreq/amd-pstate.c   |  2 --
>  drivers/cpufreq/cppc_cpufreq.c | 10 ++--------
>  drivers/cpufreq/cpufreq.c      | 16 +++++++---------
>  drivers/cpufreq/freq_table.c   |  7 +++----
>  5 files changed, 13 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index e73a66785d69d..6a6e26e1be14a 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -857,6 +857,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
>                  * governor from selecting inadequate CPU frequencies.
>                  */
>                 arch_set_max_freq_ratio(true);
> +               policy->cpuinfo.max_freq = nominal_freq;
>         }
>
>         policy->freq_table = freq_table;

This looks like a fix for acpi_cpufreq that should be sent separately.

> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index c45bc98721d24..310d5938cbdf6 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -756,8 +756,6 @@ static int amd_pstate_cpu_boost_update(struct cpufreq_policy *policy, bool on)
>         else if (policy->cpuinfo.max_freq > nominal_freq)
>                 policy->cpuinfo.max_freq = nominal_freq;
>
> -       policy->max = policy->cpuinfo.max_freq;
> -
>         if (cppc_state == AMD_PSTATE_PASSIVE) {
>                 ret = freq_qos_update_request(&cpudata->req[1], policy->cpuinfo.max_freq);
>                 if (ret < 0)
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index 9eac77c4f2944..4c46c7ea318eb 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -775,17 +775,11 @@ static int cppc_cpufreq_set_boost(struct cpufreq_policy *policy, int state)
>  {
>         struct cppc_cpudata *cpu_data = policy->driver_data;
>         struct cppc_perf_caps *caps = &cpu_data->perf_caps;
> -       int ret;
>
>         if (state)
> -               policy->max = cppc_perf_to_khz(caps, caps->highest_perf);
> +               policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->highest_perf);
>         else
> -               policy->max = cppc_perf_to_khz(caps, caps->nominal_perf);
> -       policy->cpuinfo.max_freq = policy->max;
> -
> -       ret = freq_qos_update_request(policy->max_freq_req, policy->max);
> -       if (ret < 0)
> -               return ret;
> +               policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->nominal_perf);
>
>         return 0;
>  }
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 42de32488f422..20266fb42d18d 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1500,10 +1500,14 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
>                                 goto out_destroy_policy;
>                         }
>
> +                       /*
> +                        * If boost is supported,
> +                        * init the constraint with cpuinfo.max_freq.
> +                        */
>                         ret = freq_qos_add_request(&policy->constraints,
>                                                    policy->boost_freq_req,
>                                                    FREQ_QOS_MAX,
> -                                                  FREQ_QOS_MAX_DEFAULT_VALUE);
> +                                                  policy->cpuinfo.max_freq);
>                         if (ret < 0) {
>                                 /*
>                                  * So we don't call freq_qos_remove_request() for an

Why do you need to update stuff introduced in the previous patch?

Is that because policy->cpuinfo.max_freq is not set consistently
before the changes made here?  In which case, wouldn't it be better to
make all drivers set cpuinfo.max_freq consistently before making the
changes in the second patch and fold the chunk above into the latter?

> @@ -2818,16 +2822,10 @@ int cpufreq_boost_set_sw(struct cpufreq_policy *policy, int state)
>                 return -ENXIO;
>
>         ret = cpufreq_frequency_table_cpuinfo(policy);
> -       if (ret) {
> +       if (ret)
>                 pr_err("%s: Policy frequency update failed\n", __func__);
> -               return ret;
> -       }
>
> -       ret = freq_qos_update_request(policy->max_freq_req, policy->max);
> -       if (ret < 0)
> -               return ret;
> -
> -       return 0;
> +       return ret;
>  }
>  EXPORT_SYMBOL_GPL(cpufreq_boost_set_sw);

This also looks like it belongs to the second patch in the series.

> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
> index 7f251daf03ce3..9b37f37c36389 100644
> --- a/drivers/cpufreq/freq_table.c
> +++ b/drivers/cpufreq/freq_table.c
> @@ -49,16 +49,15 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy)
>                         max_freq = freq;
>         }
>
> -       policy->min = policy->cpuinfo.min_freq = min_freq;
> -       policy->max = max_freq;
> +       policy->cpuinfo.min_freq = min_freq;
>         /*
>          * If the driver has set its own cpuinfo.max_freq above max_freq, leave
>          * it as is.
>          */
>         if (policy->cpuinfo.max_freq < max_freq)
> -               policy->max = policy->cpuinfo.max_freq = max_freq;
> +               policy->cpuinfo.max_freq = max_freq;
>
> -       if (policy->min == ~0)
> +       if (min_freq == ~0)
>                 return -EINVAL;
>         else
>                 return 0;
> --

Re: [RFC PATCH v5 6/6] cpufreq/freq_table: Allow decreasing cpuinfo.max_freq

[Rafael J. Wysocki]

On Wed, Feb 25, 2026 at 9:50 AM Pierre Gondois <pierre.gondois@arm.com> wrote:
>
> Drivers not using freq. tables update cpuinfo.max_freq in their
> .set_boost() callback. E.g. amd-pstate, cppc_cpufreq.
> Drivers relying on freq. tables and supporting boost frequencies
> rely on cpufreq_frequency_table_cpuinfo(). cpuinfo.max_freq is
> only updated if the new maximal value is higher than the previous
> one.
>
> Using the scmi-cpufreq driver which relies on freq. tables, enabling
> boost will permanently increases the cpuinfo.max_freq value.
> This patch allows to lower cpuinfo.max_freq.
>
> Note:
> commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly
> if max boost is known")
> favored having cpuinfo.max_freq reporting the maximal boosted
> frequency of a CPU instead of the maximal reachable frequency
> due to regressions in the frequency reported by cpuinfo.max
> and scaling_cur_freq.
> As stated above, this is not what most of the other cpufreq driver
> do. I assume that the following patch:
> commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to
> cover boost frequencies")
> was correct, but might not have tagged the boosted frequency with
> the CPUFREQ_BOOST_FREQ flag in the freq. table.
>
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> ---
>  drivers/cpufreq/freq_table.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
> index 9b37f37c36389..bd08cbe9e9ba3 100644
> --- a/drivers/cpufreq/freq_table.c
> +++ b/drivers/cpufreq/freq_table.c
> @@ -50,12 +50,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy)
>         }
>
>         policy->cpuinfo.min_freq = min_freq;
> -       /*
> -        * If the driver has set its own cpuinfo.max_freq above max_freq, leave
> -        * it as is.
> -        */
> -       if (policy->cpuinfo.max_freq < max_freq)
> -               policy->cpuinfo.max_freq = max_freq;
> +       policy->cpuinfo.max_freq = max_freq;
>
>         if (min_freq == ~0)
>                 return -EINVAL;
> --

How exactly does this change depend on the previous patches?

Re: [PATCH v5 0/6] cpufreq: Introduce boost frequency QoS

[Viresh Kumar]

On 25-02-26, 09:49, Pierre Gondois wrote:
> E.g.:
> On a Juno with available frequencies: 600.000, 1.000.000
> Boost frequencies: 1.200.000
> Using the cppc-cpufreq driver.

I think I suggested adding this example in one of the commits (it is useful),
not sure if it done yet ?

> Without the patches:
> # ## Init state
> scaling_max_freq:1000000
> cpuinfo_max_freq:1000000
> 
> # echo 700000 > scaling_max_freq
> scaling_max_freq:700000
> cpuinfo_max_freq:1000000
> 
> # echo 1 > ../boost
> scaling_max_freq:1200000
> cpuinfo_max_freq:1200000
> 
> # echo 800000 > scaling_max_freq
> scaling_max_freq:800000
> cpuinfo_max_freq:1200000
> 
> # echo 0 > ../boost
> scaling_max_freq:1000000
> cpuinfo_max_freq:1000000
> 
> ---
> With the patches:
> # ## Init
> scaling_max_freq:1000000
> cpuinfo_max_freq:1000000
> 
> # echo 700000 > scaling_max_freq
> scaling_max_freq:700000
> cpuinfo_max_freq:1000000
> 
> # echo 1 > ../boost
> scaling_max_freq:700000
> cpuinfo_max_freq:1200000
> 
> # echo 800000 > scaling_max_freq
> scaling_max_freq:800000
> cpuinfo_max_freq:1200000
> 
> # echo 0 > ../boost
> scaling_max_freq:800000
> cpuinfo_max_freq:1000000

-- 
viresh

Re: [PATCH v5 1/6] cpufreq: Remove per-CPU QoS constraint

[Viresh Kumar]

On 25-02-26, 09:49, Pierre Gondois wrote:
> policy->max_freq_req represents the maximum allowed frequency as
> requested by the policyX/scaling_max_freq sysfs file. This request
> applies to all CPUs of the policy. It is not possible to request
> a per-CPU maximum frequency.
> 
> Thus, the interaction between the policy boost and scaling_max_freq
> settings should be handled by adding a boost specific QoS constraint.
> This will be handled in the following patches.
> 
> This patch reverts of:
> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
> a CPU")
> 
> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> ---
>  drivers/cpufreq/cpufreq.c | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 4472bb1ec83c7..db414c052658b 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1481,10 +1481,6 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
>  
>  		blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
>  				CPUFREQ_CREATE_POLICY, policy);
> -	} else {
> -		ret = freq_qos_update_request(policy->max_freq_req, policy->max);
> -		if (ret < 0)
> -			goto out_destroy_policy;
>  	}
>  
>  	if (cpufreq_driver->get && has_target()) {

Even if this change is required, I don't think this should be applied
separately. Just reverting this will get the bug back, which was fixed by
commit 1608f0230510. Individual patches shouldn't break kernel (and bisect) as
much as possible.

-- 
viresh

Re: [PATCH v5 2/6] cpufreq: Add boost_freq_req QoS request

[Viresh Kumar]

On 11-03-26, 14:52, Rafael J. Wysocki wrote:
> On Wed, Feb 25, 2026 at 9:49 AM Pierre Gondois <pierre.gondois@arm.com> wrote:
> > -       if (policy->max_freq_req) {
> > +       if ((policy->max_freq_req && !policy->boost_supported) ||
> > +           policy->boost_freq_req) {
> 
> Are you sure?

Its messy for sure, but looks okay. We register CPUFREQ_REMOVE_POLICY when:
- max-freq-req is set and boost isn't supported
- or if boost is supported, then boost-freq-req must be set as well.

> Instead of doing this, why don't you add 1 to the policy->min_freq_req
> allocation size when boost is supported?  You'll destroy the policy if
> the allocation fails anyway.

+1

-- 
viresh

Re: [PATCH v5 3/6] cpufreq: Centralize boost freq QoS requests

[Viresh Kumar]

On 25-02-26, 09:49, Pierre Gondois wrote:
> policy_set_boost() calls the cpufreq set_boost callback.
> Update the newly added boost_freq_req request from there:
> - whenever boost is toggled
> - to cover all possible paths
> 
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> ---
>  drivers/cpufreq/cpufreq.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 50467b938668a..42de32488f422 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -603,10 +603,19 @@ static int policy_set_boost(struct cpufreq_policy *policy, bool enable)
>  	policy->boost_enabled = enable;
>  
>  	ret = cpufreq_driver->set_boost(policy, enable);
> -	if (ret)
> +	if (ret) {
>  		policy->boost_enabled = !policy->boost_enabled;
> +		return ret;
> +	}
>  
> -	return ret;
> +	ret = freq_qos_update_request(policy->boost_freq_req, policy->cpuinfo.max_freq);
> +	if (ret < 0) {
> +		policy->boost_enabled = !policy->boost_enabled;
> +		cpufreq_driver->set_boost(policy, policy->boost_enabled);
> +		return ret;
> +	}
> +
> +	return 0;

This can be:

        return ret;

and you can then drop 'return ret' from the if block.

And yes, merge with prev patch as Rafael suggested.

-- 
viresh

Re: [PATCH v5 4/6] cpufreq: Update .set_boost() callbacks to rely on boost_freq_req

[Viresh Kumar]

On 11-03-26, 17:19, Rafael J. Wysocki wrote:
> On Wed, Feb 25, 2026 at 9:50 AM Pierre Gondois <pierre.gondois@arm.com> wrote:
> >
> > In the existing .set_boost() callbacks:
> > - Don't update policy->max as this is done through the qos notifier
> >   cpufreq_notifier_max() which calls cpufreq_set_policy().
> > - Remove freq_qos_update_request() calls as the qos request is now
> >   done in policy_set_boost() and updates the new boost_freq_req
> >
> > Note:
> > cpufreq_frequency_table_cpuinfo() is also called through:
> > cpufreq_policy_online()
> > \-cpufreq_table_validate_and_sort()
> >   \-cpufreq_frequency_table_cpuinfo()
> > which relies on cpufreq_frequency_table_cpuinfo() to set
> > policy->min and max initizalization at driver init. This
> > regression is solved in the next patch.
> >
> > Note2:
> > acpi-cpufreq.c seems to be the only cpufreq driver not
> > setting cpuinfo.max_freq. Populate it the nominal frequency at
> > driver init.
> >
> > Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> > ---
> >  drivers/cpufreq/acpi-cpufreq.c |  1 +
> >  drivers/cpufreq/amd-pstate.c   |  2 --
> >  drivers/cpufreq/cppc_cpufreq.c | 10 ++--------
> >  drivers/cpufreq/cpufreq.c      | 16 +++++++---------
> >  drivers/cpufreq/freq_table.c   |  7 +++----
> >  5 files changed, 13 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> > index e73a66785d69d..6a6e26e1be14a 100644
> > --- a/drivers/cpufreq/acpi-cpufreq.c
> > +++ b/drivers/cpufreq/acpi-cpufreq.c
> > @@ -857,6 +857,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
> >                  * governor from selecting inadequate CPU frequencies.
> >                  */
> >                 arch_set_max_freq_ratio(true);
> > +               policy->cpuinfo.max_freq = nominal_freq;
> >         }
> >
> >         policy->freq_table = freq_table;
> 
> This looks like a fix for acpi_cpufreq that should be sent separately.

cpufreq_frequency_table_cpuinfo() (called before this) should always end up
setting cpuinfo.max_freq properly and so this never broke earlier.

> > diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> > index c45bc98721d24..310d5938cbdf6 100644
> > --- a/drivers/cpufreq/amd-pstate.c
> > +++ b/drivers/cpufreq/amd-pstate.c
> > @@ -756,8 +756,6 @@ static int amd_pstate_cpu_boost_update(struct cpufreq_policy *policy, bool on)
> >         else if (policy->cpuinfo.max_freq > nominal_freq)
> >                 policy->cpuinfo.max_freq = nominal_freq;
> >
> > -       policy->max = policy->cpuinfo.max_freq;
> > -
> >         if (cppc_state == AMD_PSTATE_PASSIVE) {
> >                 ret = freq_qos_update_request(&cpudata->req[1], policy->cpuinfo.max_freq);
> >                 if (ret < 0)
> > diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> > index 9eac77c4f2944..4c46c7ea318eb 100644
> > --- a/drivers/cpufreq/cppc_cpufreq.c
> > +++ b/drivers/cpufreq/cppc_cpufreq.c
> > @@ -775,17 +775,11 @@ static int cppc_cpufreq_set_boost(struct cpufreq_policy *policy, int state)
> >  {
> >         struct cppc_cpudata *cpu_data = policy->driver_data;
> >         struct cppc_perf_caps *caps = &cpu_data->perf_caps;
> > -       int ret;
> >
> >         if (state)
> > -               policy->max = cppc_perf_to_khz(caps, caps->highest_perf);
> > +               policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->highest_perf);
> >         else
> > -               policy->max = cppc_perf_to_khz(caps, caps->nominal_perf);
> > -       policy->cpuinfo.max_freq = policy->max;
> > -
> > -       ret = freq_qos_update_request(policy->max_freq_req, policy->max);
> > -       if (ret < 0)
> > -               return ret;
> > +               policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->nominal_perf);
> >
> >         return 0;
> >  }
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 42de32488f422..20266fb42d18d 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -1500,10 +1500,14 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
> >                                 goto out_destroy_policy;
> >                         }
> >
> > +                       /*
> > +                        * If boost is supported,
> > +                        * init the constraint with cpuinfo.max_freq.
> > +                        */
> >                         ret = freq_qos_add_request(&policy->constraints,
> >                                                    policy->boost_freq_req,
> >                                                    FREQ_QOS_MAX,
> > -                                                  FREQ_QOS_MAX_DEFAULT_VALUE);
> > +                                                  policy->cpuinfo.max_freq);
> >                         if (ret < 0) {
> >                                 /*
> >                                  * So we don't call freq_qos_remove_request() for an
> 
> Why do you need to update stuff introduced in the previous patch?
> 
> Is that because policy->cpuinfo.max_freq is not set consistently
> before the changes made here?  In which case, wouldn't it be better to
> make all drivers set cpuinfo.max_freq consistently before making the
> changes in the second patch and fold the chunk above into the latter?

Since cpuinfo.max_freq is set correctly earlier, I think this can be done
earlier only.

> > @@ -2818,16 +2822,10 @@ int cpufreq_boost_set_sw(struct cpufreq_policy *policy, int state)
> >                 return -ENXIO;
> >
> >         ret = cpufreq_frequency_table_cpuinfo(policy);
> > -       if (ret) {
> > +       if (ret)
> >                 pr_err("%s: Policy frequency update failed\n", __func__);
> > -               return ret;
> > -       }
> >
> > -       ret = freq_qos_update_request(policy->max_freq_req, policy->max);
> > -       if (ret < 0)
> > -               return ret;
> > -
> > -       return 0;
> > +       return ret;
> >  }
> >  EXPORT_SYMBOL_GPL(cpufreq_boost_set_sw);
> 
> This also looks like it belongs to the second patch in the series.
> 
> > diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
> > index 7f251daf03ce3..9b37f37c36389 100644
> > --- a/drivers/cpufreq/freq_table.c
> > +++ b/drivers/cpufreq/freq_table.c
> > @@ -49,16 +49,15 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy)
> >                         max_freq = freq;
> >         }
> >
> > -       policy->min = policy->cpuinfo.min_freq = min_freq;
> > -       policy->max = max_freq;
> > +       policy->cpuinfo.min_freq = min_freq;
> >         /*
> >          * If the driver has set its own cpuinfo.max_freq above max_freq, leave
> >          * it as is.
> >          */
> >         if (policy->cpuinfo.max_freq < max_freq)
> > -               policy->max = policy->cpuinfo.max_freq = max_freq;
> > +               policy->cpuinfo.max_freq = max_freq;
> >
> > -       if (policy->min == ~0)
> > +       if (min_freq == ~0)
> >                 return -EINVAL;

why are policy->min/max assignments removed here ?

-- 
viresh

Re: [PATCH v5 4/6] cpufreq: Update .set_boost() callbacks to rely on boost_freq_req

[Rafael J. Wysocki]

On Fri, Mar 13, 2026 at 10:38 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 11-03-26, 17:19, Rafael J. Wysocki wrote:
> > On Wed, Feb 25, 2026 at 9:50 AM Pierre Gondois <pierre.gondois@arm.com> wrote:
> > >
> > > In the existing .set_boost() callbacks:
> > > - Don't update policy->max as this is done through the qos notifier
> > >   cpufreq_notifier_max() which calls cpufreq_set_policy().
> > > - Remove freq_qos_update_request() calls as the qos request is now
> > >   done in policy_set_boost() and updates the new boost_freq_req
> > >
> > > Note:
> > > cpufreq_frequency_table_cpuinfo() is also called through:
> > > cpufreq_policy_online()
> > > \-cpufreq_table_validate_and_sort()
> > >   \-cpufreq_frequency_table_cpuinfo()
> > > which relies on cpufreq_frequency_table_cpuinfo() to set
> > > policy->min and max initizalization at driver init. This
> > > regression is solved in the next patch.
> > >
> > > Note2:
> > > acpi-cpufreq.c seems to be the only cpufreq driver not
> > > setting cpuinfo.max_freq. Populate it the nominal frequency at
> > > driver init.
> > >
> > > Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> > > ---
> > >  drivers/cpufreq/acpi-cpufreq.c |  1 +
> > >  drivers/cpufreq/amd-pstate.c   |  2 --
> > >  drivers/cpufreq/cppc_cpufreq.c | 10 ++--------
> > >  drivers/cpufreq/cpufreq.c      | 16 +++++++---------
> > >  drivers/cpufreq/freq_table.c   |  7 +++----
> > >  5 files changed, 13 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> > > index e73a66785d69d..6a6e26e1be14a 100644
> > > --- a/drivers/cpufreq/acpi-cpufreq.c
> > > +++ b/drivers/cpufreq/acpi-cpufreq.c
> > > @@ -857,6 +857,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
> > >                  * governor from selecting inadequate CPU frequencies.
> > >                  */
> > >                 arch_set_max_freq_ratio(true);
> > > +               policy->cpuinfo.max_freq = nominal_freq;
> > >         }
> > >
> > >         policy->freq_table = freq_table;
> >
> > This looks like a fix for acpi_cpufreq that should be sent separately.
>
> cpufreq_frequency_table_cpuinfo() (called before this) should always end up
> setting cpuinfo.max_freq properly and so this never broke earlier.

So is this change needed?

> > > diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> > > index c45bc98721d24..310d5938cbdf6 100644
> > > --- a/drivers/cpufreq/amd-pstate.c
> > > +++ b/drivers/cpufreq/amd-pstate.c
> > > @@ -756,8 +756,6 @@ static int amd_pstate_cpu_boost_update(struct cpufreq_policy *policy, bool on)
> > >         else if (policy->cpuinfo.max_freq > nominal_freq)
> > >                 policy->cpuinfo.max_freq = nominal_freq;
> > >
> > > -       policy->max = policy->cpuinfo.max_freq;
> > > -
> > >         if (cppc_state == AMD_PSTATE_PASSIVE) {
> > >                 ret = freq_qos_update_request(&cpudata->req[1], policy->cpuinfo.max_freq);
> > >                 if (ret < 0)
> > > diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> > > index 9eac77c4f2944..4c46c7ea318eb 100644
> > > --- a/drivers/cpufreq/cppc_cpufreq.c
> > > +++ b/drivers/cpufreq/cppc_cpufreq.c
> > > @@ -775,17 +775,11 @@ static int cppc_cpufreq_set_boost(struct cpufreq_policy *policy, int state)
> > >  {
> > >         struct cppc_cpudata *cpu_data = policy->driver_data;
> > >         struct cppc_perf_caps *caps = &cpu_data->perf_caps;
> > > -       int ret;
> > >
> > >         if (state)
> > > -               policy->max = cppc_perf_to_khz(caps, caps->highest_perf);
> > > +               policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->highest_perf);
> > >         else
> > > -               policy->max = cppc_perf_to_khz(caps, caps->nominal_perf);
> > > -       policy->cpuinfo.max_freq = policy->max;
> > > -
> > > -       ret = freq_qos_update_request(policy->max_freq_req, policy->max);
> > > -       if (ret < 0)
> > > -               return ret;
> > > +               policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->nominal_perf);
> > >
> > >         return 0;
> > >  }
> > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > > index 42de32488f422..20266fb42d18d 100644
> > > --- a/drivers/cpufreq/cpufreq.c
> > > +++ b/drivers/cpufreq/cpufreq.c
> > > @@ -1500,10 +1500,14 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
> > >                                 goto out_destroy_policy;
> > >                         }
> > >
> > > +                       /*
> > > +                        * If boost is supported,
> > > +                        * init the constraint with cpuinfo.max_freq.
> > > +                        */
> > >                         ret = freq_qos_add_request(&policy->constraints,
> > >                                                    policy->boost_freq_req,
> > >                                                    FREQ_QOS_MAX,
> > > -                                                  FREQ_QOS_MAX_DEFAULT_VALUE);
> > > +                                                  policy->cpuinfo.max_freq);
> > >                         if (ret < 0) {
> > >                                 /*
> > >                                  * So we don't call freq_qos_remove_request() for an
> >
> > Why do you need to update stuff introduced in the previous patch?
> >
> > Is that because policy->cpuinfo.max_freq is not set consistently
> > before the changes made here?  In which case, wouldn't it be better to
> > make all drivers set cpuinfo.max_freq consistently before making the
> > changes in the second patch and fold the chunk above into the latter?
>
> Since cpuinfo.max_freq is set correctly earlier, I think this can be done
> earlier only.

I'm not sure what you mean.

To clarify my point, the question really is what prevents patch [2/6]
from passing policy->cpuinfo.max_freq to freq_qos_add_request() as the
last argument right away.

Re: [PATCH v5 0/6] cpufreq: Introduce boost frequency QoS

[Pierre Gondois]

On 3/13/26 09:13, Viresh Kumar wrote:
> On 25-02-26, 09:49, Pierre Gondois wrote:
>> E.g.:
>> On a Juno with available frequencies: 600.000, 1.000.000
>> Boost frequencies: 1.200.000
>> Using the cppc-cpufreq driver.
> I think I suggested adding this example in one of the commits (it is useful),
> not sure if it done yet ?
I might have missed the comment sorry, I ll add it.


>
>> Without the patches:
>> # ## Init state
>> scaling_max_freq:1000000
>> cpuinfo_max_freq:1000000
>>
>> # echo 700000 > scaling_max_freq
>> scaling_max_freq:700000
>> cpuinfo_max_freq:1000000
>>
>> # echo 1 > ../boost
>> scaling_max_freq:1200000
>> cpuinfo_max_freq:1200000
>>
>> # echo 800000 > scaling_max_freq
>> scaling_max_freq:800000
>> cpuinfo_max_freq:1200000
>>
>> # echo 0 > ../boost
>> scaling_max_freq:1000000
>> cpuinfo_max_freq:1000000
>>
>> ---
>> With the patches:
>> # ## Init
>> scaling_max_freq:1000000
>> cpuinfo_max_freq:1000000
>>
>> # echo 700000 > scaling_max_freq
>> scaling_max_freq:700000
>> cpuinfo_max_freq:1000000
>>
>> # echo 1 > ../boost
>> scaling_max_freq:700000
>> cpuinfo_max_freq:1200000
>>
>> # echo 800000 > scaling_max_freq
>> scaling_max_freq:800000
>> cpuinfo_max_freq:1200000
>>
>> # echo 0 > ../boost
>> scaling_max_freq:800000
>> cpuinfo_max_freq:1000000

Re: [PATCH v5 3/6] cpufreq: Centralize boost freq QoS requests

[Pierre Gondois]

On 3/13/26 10:22, Viresh Kumar wrote:
> On 25-02-26, 09:49, Pierre Gondois wrote:
>> policy_set_boost() calls the cpufreq set_boost callback.
>> Update the newly added boost_freq_req request from there:
>> - whenever boost is toggled
>> - to cover all possible paths
>>
>> Signed-off-by: Pierre Gondois<pierre.gondois@arm.com>
>> ---
>>   drivers/cpufreq/cpufreq.c | 13 +++++++++++--
>>   1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 50467b938668a..42de32488f422 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -603,10 +603,19 @@ static int policy_set_boost(struct cpufreq_policy *policy, bool enable)
>>   	policy->boost_enabled = enable;
>>   
>>   	ret = cpufreq_driver->set_boost(policy, enable);
>> -	if (ret)
>> +	if (ret) {
>>   		policy->boost_enabled = !policy->boost_enabled;
>> +		return ret;
>> +	}
>>   
>> -	return ret;
>> +	ret = freq_qos_update_request(policy->boost_freq_req, policy->cpuinfo.max_freq);
>> +	if (ret < 0) {
>> +		policy->boost_enabled = !policy->boost_enabled;
>> +		cpufreq_driver->set_boost(policy, policy->boost_enabled);
>> +		return ret;
>> +	}
>> +
>> +	return 0;
> This can be:
>
>          return ret;
>
> and you can then drop 'return ret' from the if block.
>
> And yes, merge with prev patch as Rafael suggested.
>
Ok sure.

Re: [PATCH v5 4/6] cpufreq: Update .set_boost() callbacks to rely on boost_freq_req

[Pierre Gondois]

On 3/13/26 12:43, Rafael J. Wysocki wrote:
> On Fri, Mar 13, 2026 at 10:38 AM Viresh Kumar<viresh.kumar@linaro.org> wrote:
>> On 11-03-26, 17:19, Rafael J. Wysocki wrote:
>>> On Wed, Feb 25, 2026 at 9:50 AM Pierre Gondois<pierre.gondois@arm.com> wrote:
>>>> In the existing .set_boost() callbacks:
>>>> - Don't update policy->max as this is done through the qos notifier
>>>>    cpufreq_notifier_max() which calls cpufreq_set_policy().
>>>> - Remove freq_qos_update_request() calls as the qos request is now
>>>>    done in policy_set_boost() and updates the new boost_freq_req
>>>>
>>>> Note:
>>>> cpufreq_frequency_table_cpuinfo() is also called through:
>>>> cpufreq_policy_online()
>>>> \-cpufreq_table_validate_and_sort()
>>>>    \-cpufreq_frequency_table_cpuinfo()
>>>> which relies on cpufreq_frequency_table_cpuinfo() to set
>>>> policy->min and max initizalization at driver init. This
>>>> regression is solved in the next patch.
>>>>
>>>> Note2:
>>>> acpi-cpufreq.c seems to be the only cpufreq driver not
>>>> setting cpuinfo.max_freq. Populate it the nominal frequency at
>>>> driver init.
>>>>
>>>> Signed-off-by: Pierre Gondois<pierre.gondois@arm.com>
>>>> ---
>>>>   drivers/cpufreq/acpi-cpufreq.c |  1 +
>>>>   drivers/cpufreq/amd-pstate.c   |  2 --
>>>>   drivers/cpufreq/cppc_cpufreq.c | 10 ++--------
>>>>   drivers/cpufreq/cpufreq.c      | 16 +++++++---------
>>>>   drivers/cpufreq/freq_table.c   |  7 +++----
>>>>   5 files changed, 13 insertions(+), 23 deletions(-)
>>>>
>>>> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
>>>> index e73a66785d69d..6a6e26e1be14a 100644
>>>> --- a/drivers/cpufreq/acpi-cpufreq.c
>>>> +++ b/drivers/cpufreq/acpi-cpufreq.c
>>>> @@ -857,6 +857,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
>>>>                   * governor from selecting inadequate CPU frequencies.
>>>>                   */
>>>>                  arch_set_max_freq_ratio(true);
>>>> +               policy->cpuinfo.max_freq = nominal_freq;
>>>>          }
>>>>
>>>>          policy->freq_table = freq_table;
>>> This looks like a fix for acpi_cpufreq that should be sent separately.
>> cpufreq_frequency_table_cpuinfo() (called before this) should always end up
>> setting cpuinfo.max_freq properly and so this never broke earlier.
> So is this change needed?

Yes right indeed, this should be removed.


>>>> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
>>>> index c45bc98721d24..310d5938cbdf6 100644
>>>> --- a/drivers/cpufreq/amd-pstate.c
>>>> +++ b/drivers/cpufreq/amd-pstate.c
>>>> @@ -756,8 +756,6 @@ static int amd_pstate_cpu_boost_update(struct cpufreq_policy *policy, bool on)
>>>>          else if (policy->cpuinfo.max_freq > nominal_freq)
>>>>                  policy->cpuinfo.max_freq = nominal_freq;
>>>>
>>>> -       policy->max = policy->cpuinfo.max_freq;
>>>> -
>>>>          if (cppc_state == AMD_PSTATE_PASSIVE) {
>>>>                  ret = freq_qos_update_request(&cpudata->req[1], policy->cpuinfo.max_freq);
>>>>                  if (ret < 0)
>>>> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
>>>> index 9eac77c4f2944..4c46c7ea318eb 100644
>>>> --- a/drivers/cpufreq/cppc_cpufreq.c
>>>> +++ b/drivers/cpufreq/cppc_cpufreq.c
>>>> @@ -775,17 +775,11 @@ static int cppc_cpufreq_set_boost(struct cpufreq_policy *policy, int state)
>>>>   {
>>>>          struct cppc_cpudata *cpu_data = policy->driver_data;
>>>>          struct cppc_perf_caps *caps = &cpu_data->perf_caps;
>>>> -       int ret;
>>>>
>>>>          if (state)
>>>> -               policy->max = cppc_perf_to_khz(caps, caps->highest_perf);
>>>> +               policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->highest_perf);
>>>>          else
>>>> -               policy->max = cppc_perf_to_khz(caps, caps->nominal_perf);
>>>> -       policy->cpuinfo.max_freq = policy->max;
>>>> -
>>>> -       ret = freq_qos_update_request(policy->max_freq_req, policy->max);
>>>> -       if (ret < 0)
>>>> -               return ret;
>>>> +               policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->nominal_perf);
>>>>
>>>>          return 0;
>>>>   }
>>>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>>>> index 42de32488f422..20266fb42d18d 100644
>>>> --- a/drivers/cpufreq/cpufreq.c
>>>> +++ b/drivers/cpufreq/cpufreq.c
>>>> @@ -1500,10 +1500,14 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
>>>>                                  goto out_destroy_policy;
>>>>                          }
>>>>
>>>> +                       /*
>>>> +                        * If boost is supported,
>>>> +                        * init the constraint with cpuinfo.max_freq.
>>>> +                        */
>>>>                          ret = freq_qos_add_request(&policy->constraints,
>>>>                                                     policy->boost_freq_req,
>>>>                                                     FREQ_QOS_MAX,
>>>> -                                                  FREQ_QOS_MAX_DEFAULT_VALUE);
>>>> +                                                  policy->cpuinfo.max_freq);
>>>>                          if (ret < 0) {
>>>>                                  /*
>>>>                                   * So we don't call freq_qos_remove_request() for an
>>> Why do you need to update stuff introduced in the previous patch?
>>>
>>> Is that because policy->cpuinfo.max_freq is not set consistently
>>> before the changes made here?  In which case, wouldn't it be better to
>>> make all drivers set cpuinfo.max_freq consistently before making the
>>> changes in the second patch and fold the chunk above into the latter?
>> Since cpuinfo.max_freq is set correctly earlier, I think this can be done
>> earlier only.
> I'm not sure what you mean.
>
> To clarify my point, the question really is what prevents patch [2/6]
> from passing policy->cpuinfo.max_freq to freq_qos_add_request() as the
> last argument right away.

Nothing should prevent from doing that I think.

The first patchset was only intending to add a boost QoS hook,
then additional modifications have been added at the end of the
serie. I will modify the order to make it easier to follow.

Re: [PATCH v5 1/6] cpufreq: Remove per-CPU QoS constraint

[Pierre Gondois]

On 3/13/26 09:57, Viresh Kumar wrote:
> On 25-02-26, 09:49, Pierre Gondois wrote:
>> policy->max_freq_req represents the maximum allowed frequency as
>> requested by the policyX/scaling_max_freq sysfs file. This request
>> applies to all CPUs of the policy. It is not possible to request
>> a per-CPU maximum frequency.
>>
>> Thus, the interaction between the policy boost and scaling_max_freq
>> settings should be handled by adding a boost specific QoS constraint.
>> This will be handled in the following patches.
>>
>> This patch reverts of:
>> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
>> a CPU")
>>
>> Reviewed-by: Lifeng Zheng<zhenglifeng1@huawei.com>
>> Signed-off-by: Pierre Gondois<pierre.gondois@arm.com>
>> ---
>>   drivers/cpufreq/cpufreq.c | 4 ----
>>   1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 4472bb1ec83c7..db414c052658b 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -1481,10 +1481,6 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
>>   
>>   		blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
>>   				CPUFREQ_CREATE_POLICY, policy);
>> -	} else {
>> -		ret = freq_qos_update_request(policy->max_freq_req, policy->max);
>> -		if (ret < 0)
>> -			goto out_destroy_policy;
>>   	}
>>   
>>   	if (cpufreq_driver->get && has_target()) {
> Even if this change is required, I don't think this should be applied
> separately. Just reverting this will get the bug back, which was fixed by
> commit 1608f0230510. Individual patches shouldn't break kernel (and bisect) as
> much as possible.
>
I think Lifeng said the issue was not present anymore:

https://lore.kernel.org/all/8c174633-4005-4e52-bb6b-9e9c6181b12b@huawei.com/

I ll check if I can reproduce it with the base kernel.

Re: [RFC PATCH v5 6/6] cpufreq/freq_table: Allow decreasing cpuinfo.max_freq

[Pierre Gondois]

On 3/11/26 17:24, Rafael J. Wysocki wrote:
> On Wed, Feb 25, 2026 at 9:50 AM Pierre Gondois<pierre.gondois@arm.com> wrote:
>> Drivers not using freq. tables update cpuinfo.max_freq in their
>> .set_boost() callback. E.g. amd-pstate, cppc_cpufreq.
>> Drivers relying on freq. tables and supporting boost frequencies
>> rely on cpufreq_frequency_table_cpuinfo(). cpuinfo.max_freq is
>> only updated if the new maximal value is higher than the previous
>> one.
>>
>> Using the scmi-cpufreq driver which relies on freq. tables, enabling
>> boost will permanently increases the cpuinfo.max_freq value.
>> This patch allows to lower cpuinfo.max_freq.
>>
>> Note:
>> commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly
>> if max boost is known")
>> favored having cpuinfo.max_freq reporting the maximal boosted
>> frequency of a CPU instead of the maximal reachable frequency
>> due to regressions in the frequency reported by cpuinfo.max
>> and scaling_cur_freq.
>> As stated above, this is not what most of the other cpufreq driver
>> do. I assume that the following patch:
>> commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to
>> cover boost frequencies")
>> was correct, but might not have tagged the boosted frequency with
>> the CPUFREQ_BOOST_FREQ flag in the freq. table.
>>
>> Signed-off-by: Pierre Gondois<pierre.gondois@arm.com>
>> ---
>>   drivers/cpufreq/freq_table.c | 7 +------
>>   1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
>> index 9b37f37c36389..bd08cbe9e9ba3 100644
>> --- a/drivers/cpufreq/freq_table.c
>> +++ b/drivers/cpufreq/freq_table.c
>> @@ -50,12 +50,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy)
>>          }
>>
>>          policy->cpuinfo.min_freq = min_freq;
>> -       /*
>> -        * If the driver has set its own cpuinfo.max_freq above max_freq, leave
>> -        * it as is.
>> -        */
>> -       if (policy->cpuinfo.max_freq < max_freq)
>> -               policy->cpuinfo.max_freq = max_freq;
>> +       policy->cpuinfo.max_freq = max_freq;
>>
>>          if (min_freq == ~0)
>>                  return -EINVAL;
>> --
> How exactly does this change depend on the previous patches?

Without it, the pattern in the cover letter:

# ## Init
scaling_max_freq:1000000
cpuinfo_max_freq:1000000

# echo 700000 > scaling_max_freq
scaling_max_freq:700000
cpuinfo_max_freq:1000000

# echo 1 > ../boost
scaling_max_freq:700000
cpuinfo_max_freq:1200000

# echo 800000 > scaling_max_freq
scaling_max_freq:800000
cpuinfo_max_freq:1200000

# echo 0 > ../boost
scaling_max_freq:800000
cpuinfo_max_freq:1000000

doesn't work when using the scmi-cpufreq driver

Re: [PATCH v5 2/6] cpufreq: Add boost_freq_req QoS request

[Pierre Gondois]

On 3/11/26 14:57, Rafael J. Wysocki wrote:
> On Wed, Mar 11, 2026 at 2:52 PM Rafael J. Wysocki<rafael@kernel.org> wrote:
>> On Wed, Feb 25, 2026 at 9:49 AM Pierre Gondois<pierre.gondois@arm.com> wrote:
>>> The Power Management Quality of Service (PM QoS) allows to
>>> aggregate constraints from multiple entities. It is currently
>>> used to manage the min/max frequency of a given policy.
>>>
>>> Frequency constraints can come for instance from:
>>> - Thermal framework: acpi_thermal_cpufreq_init()
>>> - Firmware: _PPC objects: acpi_processor_ppc_init()
>>> - User: by setting policyX/scaling_[min|max]_freq
>>> The minimum of the max frequency constraints is used to compute
>>> the resulting maximum allowed frequency.
>>>
>>> When enabling boost frequencies, the same frequency request object
>>> (policy->max_freq_req) as to handle requests from users is used.
>>> As a result, when setting:
>>> - scaling_max_freq
>>> - boost
>>> The last sysfs file used overwrites the request from the other
>>> sysfs file.
>>>
>>> To avoid this, create a per-policy boost_freq_req to save the boost
>>> constraints instead of overwriting the last scaling_max_freq
>>> constraint.
>>>
>>> Signed-off-by: Pierre Gondois<pierre.gondois@arm.com>
>>> ---
>>>   drivers/cpufreq/cpufreq.c | 37 ++++++++++++++++++++++++++++++++-----
>>>   include/linux/cpufreq.h   |  1 +
>>>   2 files changed, 33 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>>> index db414c052658b..50467b938668a 100644
>>> --- a/drivers/cpufreq/cpufreq.c
>>> +++ b/drivers/cpufreq/cpufreq.c
>>> @@ -1359,17 +1359,21 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
>>>          /* Cancel any pending policy->update work before freeing the policy. */
>>>          cancel_work_sync(&policy->update);
>>>
>>> -       if (policy->max_freq_req) {
>>> +       if ((policy->max_freq_req && !policy->boost_supported) ||
>>> +           policy->boost_freq_req) {
>> Are you sure?
>>
>>>                  /*
>>> -                * Remove max_freq_req after sending CPUFREQ_REMOVE_POLICY
>>> -                * notification, since CPUFREQ_CREATE_POLICY notification was
>>> -                * sent after adding max_freq_req earlier.
>>> +                * Remove max/boost _freq_req after sending CPUFREQ_REMOVE_POLICY
>>> +                * notification, since CPUFREQ_CREATE_POLICY notification was sent
>>> +                * after adding max/boost _freq_req earlier.
>>>                   */
>>>                  blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
>>>                                               CPUFREQ_REMOVE_POLICY, policy);
>>> -               freq_qos_remove_request(policy->max_freq_req);
>>>          }
>>>
>>> +       freq_qos_remove_request(policy->boost_freq_req);
>>> +       kfree(policy->boost_freq_req);
>>> +
>>> +       freq_qos_remove_request(policy->max_freq_req);
>>>          freq_qos_remove_request(policy->min_freq_req);
>>>          kfree(policy->min_freq_req);
>>>
>>> @@ -1479,6 +1483,29 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
>>>                          goto out_destroy_policy;
>>>                  }
>>>
>>> +               if (policy->boost_supported) {
>>> +                       policy->boost_freq_req = kzalloc(sizeof(*policy->boost_freq_req),
>>> +                                                        GFP_KERNEL);
>> Instead of doing this, why don't you add 1 to the policy->min_freq_req
>> allocation size when boost is supported?  You'll destroy the policy if
>> the allocation fails anyway.


Yes right,
this would make the error handling much simpler to follow.

On the other hand Viresh seems to have acknowledged the logic,
so whatever seems is better to both of you.


>>> +                       if (!policy->boost_freq_req) {
>>> +                               ret = -ENOMEM;
>>> +                               goto out_destroy_policy;
>>> +                       }
>>> +
>>> +                       ret = freq_qos_add_request(&policy->constraints,
>>> +                                                  policy->boost_freq_req,
>>> +                                                  FREQ_QOS_MAX,
>>> +                                                  FREQ_QOS_MAX_DEFAULT_VALUE);
>>> +                       if (ret < 0) {
>>> +                               /*
>>> +                                * So we don't call freq_qos_remove_request() for an
>>> +                                * uninitialized request.
>>> +                                */
>>> +                               kfree(policy->boost_freq_req);
>>> +                               policy->boost_freq_req = NULL;
>>> +                               goto out_destroy_policy;
>>> +                       }
>>> +               }
>> Then you can put this block before the policy->min_freq_req addition
>> and the corresponding update of cpufreq_policy_free() will be more
>> straightforward.
>>
>> BTW, if I'm not mistaken, there is a bug in the current
>> cpufreq_policy_free() because it may attempt to remove a NULL freq QoS
>> request for policy->min_freq_req.  I'll send a patch for that later if
>> I can confirm it.
> Fortunately, freq_qos_remove_request() checks its argument against
> NULL, never mind.
>
> Of course, this means that
> freq_qos_remove_request(policy->max_freq_req) need not be there under
> the if (policy->max_freq_req) in cpufreq_policy_free() which you have
> noticed.

Re: [PATCH v5 2/6] cpufreq: Add boost_freq_req QoS request

[Rafael J. Wysocki]

On Fri, Mar 13, 2026 at 3:30 PM Pierre Gondois <pierre.gondois@arm.com> wrote:
>
>
> On 3/11/26 14:57, Rafael J. Wysocki wrote:
> > On Wed, Mar 11, 2026 at 2:52 PM Rafael J. Wysocki<rafael@kernel.org> wrote:
> >> On Wed, Feb 25, 2026 at 9:49 AM Pierre Gondois<pierre.gondois@arm.com> wrote:
> >>> The Power Management Quality of Service (PM QoS) allows to
> >>> aggregate constraints from multiple entities. It is currently
> >>> used to manage the min/max frequency of a given policy.
> >>>
> >>> Frequency constraints can come for instance from:
> >>> - Thermal framework: acpi_thermal_cpufreq_init()
> >>> - Firmware: _PPC objects: acpi_processor_ppc_init()
> >>> - User: by setting policyX/scaling_[min|max]_freq
> >>> The minimum of the max frequency constraints is used to compute
> >>> the resulting maximum allowed frequency.
> >>>
> >>> When enabling boost frequencies, the same frequency request object
> >>> (policy->max_freq_req) as to handle requests from users is used.
> >>> As a result, when setting:
> >>> - scaling_max_freq
> >>> - boost
> >>> The last sysfs file used overwrites the request from the other
> >>> sysfs file.
> >>>
> >>> To avoid this, create a per-policy boost_freq_req to save the boost
> >>> constraints instead of overwriting the last scaling_max_freq
> >>> constraint.
> >>>
> >>> Signed-off-by: Pierre Gondois<pierre.gondois@arm.com>
> >>> ---
> >>>   drivers/cpufreq/cpufreq.c | 37 ++++++++++++++++++++++++++++++++-----
> >>>   include/linux/cpufreq.h   |  1 +
> >>>   2 files changed, 33 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> >>> index db414c052658b..50467b938668a 100644
> >>> --- a/drivers/cpufreq/cpufreq.c
> >>> +++ b/drivers/cpufreq/cpufreq.c
> >>> @@ -1359,17 +1359,21 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
> >>>          /* Cancel any pending policy->update work before freeing the policy. */
> >>>          cancel_work_sync(&policy->update);
> >>>
> >>> -       if (policy->max_freq_req) {
> >>> +       if ((policy->max_freq_req && !policy->boost_supported) ||
> >>> +           policy->boost_freq_req) {
> >> Are you sure?
> >>
> >>>                  /*
> >>> -                * Remove max_freq_req after sending CPUFREQ_REMOVE_POLICY
> >>> -                * notification, since CPUFREQ_CREATE_POLICY notification was
> >>> -                * sent after adding max_freq_req earlier.
> >>> +                * Remove max/boost _freq_req after sending CPUFREQ_REMOVE_POLICY
> >>> +                * notification, since CPUFREQ_CREATE_POLICY notification was sent
> >>> +                * after adding max/boost _freq_req earlier.
> >>>                   */
> >>>                  blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> >>>                                               CPUFREQ_REMOVE_POLICY, policy);
> >>> -               freq_qos_remove_request(policy->max_freq_req);
> >>>          }
> >>>
> >>> +       freq_qos_remove_request(policy->boost_freq_req);
> >>> +       kfree(policy->boost_freq_req);
> >>> +
> >>> +       freq_qos_remove_request(policy->max_freq_req);
> >>>          freq_qos_remove_request(policy->min_freq_req);
> >>>          kfree(policy->min_freq_req);
> >>>
> >>> @@ -1479,6 +1483,29 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
> >>>                          goto out_destroy_policy;
> >>>                  }
> >>>
> >>> +               if (policy->boost_supported) {
> >>> +                       policy->boost_freq_req = kzalloc(sizeof(*policy->boost_freq_req),
> >>> +                                                        GFP_KERNEL);
> >> Instead of doing this, why don't you add 1 to the policy->min_freq_req
> >> allocation size when boost is supported?  You'll destroy the policy if
> >> the allocation fails anyway.
>
>
> Yes right,
> this would make the error handling much simpler to follow.
>
> On the other hand Viresh seems to have acknowledged the logic,

But he has also said "+1" to this one. :-)

> so whatever seems is better to both of you.

I think we agree.

Re: [PATCH v5 2/6] cpufreq: Add boost_freq_req QoS request

[Pierre Gondois]

On 3/13/26 16:31, Rafael J. Wysocki wrote:
> On Fri, Mar 13, 2026 at 3:30 PM Pierre Gondois <pierre.gondois@arm.com> wrote:
>>
>> On 3/11/26 14:57, Rafael J. Wysocki wrote:
>>> On Wed, Mar 11, 2026 at 2:52 PM Rafael J. Wysocki<rafael@kernel.org> wrote:
>>>> On Wed, Feb 25, 2026 at 9:49 AM Pierre Gondois<pierre.gondois@arm.com> wrote:
>>>>> The Power Management Quality of Service (PM QoS) allows to
>>>>> aggregate constraints from multiple entities. It is currently
>>>>> used to manage the min/max frequency of a given policy.
>>>>>
>>>>> Frequency constraints can come for instance from:
>>>>> - Thermal framework: acpi_thermal_cpufreq_init()
>>>>> - Firmware: _PPC objects: acpi_processor_ppc_init()
>>>>> - User: by setting policyX/scaling_[min|max]_freq
>>>>> The minimum of the max frequency constraints is used to compute
>>>>> the resulting maximum allowed frequency.
>>>>>
>>>>> When enabling boost frequencies, the same frequency request object
>>>>> (policy->max_freq_req) as to handle requests from users is used.
>>>>> As a result, when setting:
>>>>> - scaling_max_freq
>>>>> - boost
>>>>> The last sysfs file used overwrites the request from the other
>>>>> sysfs file.
>>>>>
>>>>> To avoid this, create a per-policy boost_freq_req to save the boost
>>>>> constraints instead of overwriting the last scaling_max_freq
>>>>> constraint.
>>>>>
>>>>> Signed-off-by: Pierre Gondois<pierre.gondois@arm.com>
>>>>> ---
>>>>>    drivers/cpufreq/cpufreq.c | 37 ++++++++++++++++++++++++++++++++-----
>>>>>    include/linux/cpufreq.h   |  1 +
>>>>>    2 files changed, 33 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>>>>> index db414c052658b..50467b938668a 100644
>>>>> --- a/drivers/cpufreq/cpufreq.c
>>>>> +++ b/drivers/cpufreq/cpufreq.c
>>>>> @@ -1359,17 +1359,21 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
>>>>>           /* Cancel any pending policy->update work before freeing the policy. */
>>>>>           cancel_work_sync(&policy->update);
>>>>>
>>>>> -       if (policy->max_freq_req) {
>>>>> +       if ((policy->max_freq_req && !policy->boost_supported) ||
>>>>> +           policy->boost_freq_req) {
>>>> Are you sure?
>>>>
>>>>>                   /*
>>>>> -                * Remove max_freq_req after sending CPUFREQ_REMOVE_POLICY
>>>>> -                * notification, since CPUFREQ_CREATE_POLICY notification was
>>>>> -                * sent after adding max_freq_req earlier.
>>>>> +                * Remove max/boost _freq_req after sending CPUFREQ_REMOVE_POLICY
>>>>> +                * notification, since CPUFREQ_CREATE_POLICY notification was sent
>>>>> +                * after adding max/boost _freq_req earlier.
>>>>>                    */
>>>>>                   blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
>>>>>                                                CPUFREQ_REMOVE_POLICY, policy);
>>>>> -               freq_qos_remove_request(policy->max_freq_req);
>>>>>           }
>>>>>
>>>>> +       freq_qos_remove_request(policy->boost_freq_req);
>>>>> +       kfree(policy->boost_freq_req);
>>>>> +
>>>>> +       freq_qos_remove_request(policy->max_freq_req);
>>>>>           freq_qos_remove_request(policy->min_freq_req);
>>>>>           kfree(policy->min_freq_req);
>>>>>
>>>>> @@ -1479,6 +1483,29 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
>>>>>                           goto out_destroy_policy;
>>>>>                   }
>>>>>
>>>>> +               if (policy->boost_supported) {
>>>>> +                       policy->boost_freq_req = kzalloc(sizeof(*policy->boost_freq_req),
>>>>> +                                                        GFP_KERNEL);
>>>> Instead of doing this, why don't you add 1 to the policy->min_freq_req
>>>> allocation size when boost is supported?  You'll destroy the policy if
>>>> the allocation fails anyway.
>>
>> Yes right,
>> this would make the error handling much simpler to follow.
>>
>> On the other hand Viresh seems to have acknowledged the logic,
> But he has also said "+1" to this one. :-)

ah right indeed


>
>> so whatever seems is better to both of you.
> I think we agree.

Re: [PATCH v5 1/6] cpufreq: Remove per-CPU QoS constraint

[Pierre Gondois]

On 3/13/26 09:57, Viresh Kumar wrote:
> On 25-02-26, 09:49, Pierre Gondois wrote:
>> policy->max_freq_req represents the maximum allowed frequency as
>> requested by the policyX/scaling_max_freq sysfs file. This request
>> applies to all CPUs of the policy. It is not possible to request
>> a per-CPU maximum frequency.
>>
>> Thus, the interaction between the policy boost and scaling_max_freq
>> settings should be handled by adding a boost specific QoS constraint.
>> This will be handled in the following patches.
>>
>> This patch reverts of:
>> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
>> a CPU")
>>
>> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
>> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
>> ---
>>   drivers/cpufreq/cpufreq.c | 4 ----
>>   1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 4472bb1ec83c7..db414c052658b 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -1481,10 +1481,6 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
>>   
>>   		blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
>>   				CPUFREQ_CREATE_POLICY, policy);
>> -	} else {
>> -		ret = freq_qos_update_request(policy->max_freq_req, policy->max);
>> -		if (ret < 0)
>> -			goto out_destroy_policy;
>>   	}
>>   
>>   	if (cpufreq_driver->get && has_target()) {
> Even if this change is required, I don't think this should be applied
> separately. Just reverting this will get the bug back, which was fixed by
> commit 1608f0230510. Individual patches shouldn't break kernel (and bisect) as
> much as possible.
>
I could not reproduce the original issue.

At the time of the patch and still now, calls to
freq_qos_update_request() are checked against negative values.
The only exception is when using the scaling_max_frequency sysfs
entry, but this is out of the scope.

So I don't see how:

commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging a CPU")

can prevent a CPU to reach the boost frequency.  The only path that
could fail and that I could reproduce was fixed by:

https://lore.kernel.org/all/852ff11c589e6300730d207baac195b2d9d8b95f.1745511526.git.viresh.kumar@linaro.org/

So the current conclusion is that "cpufreq: Fix re-boost issue after 
hotplugging a CPU"
was not the real fix

Re: [PATCH v5 1/6] cpufreq: Remove per-CPU QoS constraint

[Rafael J. Wysocki]

On Mon, Mar 16, 2026 at 3:46 PM Pierre Gondois <pierre.gondois@arm.com> wrote:
>
>
> On 3/13/26 09:57, Viresh Kumar wrote:
> > On 25-02-26, 09:49, Pierre Gondois wrote:
> >> policy->max_freq_req represents the maximum allowed frequency as
> >> requested by the policyX/scaling_max_freq sysfs file. This request
> >> applies to all CPUs of the policy. It is not possible to request
> >> a per-CPU maximum frequency.
> >>
> >> Thus, the interaction between the policy boost and scaling_max_freq
> >> settings should be handled by adding a boost specific QoS constraint.
> >> This will be handled in the following patches.
> >>
> >> This patch reverts of:
> >> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
> >> a CPU")
> >>
> >> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
> >> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> >> ---
> >>   drivers/cpufreq/cpufreq.c | 4 ----
> >>   1 file changed, 4 deletions(-)
> >>
> >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> >> index 4472bb1ec83c7..db414c052658b 100644
> >> --- a/drivers/cpufreq/cpufreq.c
> >> +++ b/drivers/cpufreq/cpufreq.c
> >> @@ -1481,10 +1481,6 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
> >>
> >>              blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> >>                              CPUFREQ_CREATE_POLICY, policy);
> >> -    } else {
> >> -            ret = freq_qos_update_request(policy->max_freq_req, policy->max);
> >> -            if (ret < 0)
> >> -                    goto out_destroy_policy;
> >>      }
> >>
> >>      if (cpufreq_driver->get && has_target()) {
> > Even if this change is required, I don't think this should be applied
> > separately. Just reverting this will get the bug back, which was fixed by
> > commit 1608f0230510. Individual patches shouldn't break kernel (and bisect) as
> > much as possible.
> >
> I could not reproduce the original issue.
>
> At the time of the patch and still now, calls to
> freq_qos_update_request() are checked against negative values.
> The only exception is when using the scaling_max_frequency sysfs
> entry, but this is out of the scope.
>
> So I don't see how:
>
> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging a CPU")
>
> can prevent a CPU to reach the boost frequency.  The only path that
> could fail and that I could reproduce was fixed by:
>
> https://lore.kernel.org/all/852ff11c589e6300730d207baac195b2d9d8b95f.1745511526.git.viresh.kumar@linaro.org/
>
> So the current conclusion is that "cpufreq: Fix re-boost issue after
> hotplugging a CPU"
> was not the real fix

OK

I gather then that the $subject patch can be applied without the rest
of the series, can't it?

It would be good to update the changelog with all of the relevant
information though.

Re: [PATCH v5 1/6] cpufreq: Remove per-CPU QoS constraint

[zhenglifeng (A)]

On 3/16/2026 10:45 PM, Pierre Gondois wrote:
> 
> On 3/13/26 09:57, Viresh Kumar wrote:
>> On 25-02-26, 09:49, Pierre Gondois wrote:
>>> policy->max_freq_req represents the maximum allowed frequency as
>>> requested by the policyX/scaling_max_freq sysfs file. This request
>>> applies to all CPUs of the policy. It is not possible to request
>>> a per-CPU maximum frequency.
>>>
>>> Thus, the interaction between the policy boost and scaling_max_freq
>>> settings should be handled by adding a boost specific QoS constraint.
>>> This will be handled in the following patches.
>>>
>>> This patch reverts of:
>>> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
>>> a CPU")
>>>
>>> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
>>> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
>>> ---
>>>   drivers/cpufreq/cpufreq.c | 4 ----
>>>   1 file changed, 4 deletions(-)
>>>
>>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>>> index 4472bb1ec83c7..db414c052658b 100644
>>> --- a/drivers/cpufreq/cpufreq.c
>>> +++ b/drivers/cpufreq/cpufreq.c
>>> @@ -1481,10 +1481,6 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
>>>             blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
>>>                   CPUFREQ_CREATE_POLICY, policy);
>>> -    } else {
>>> -        ret = freq_qos_update_request(policy->max_freq_req, policy->max);
>>> -        if (ret < 0)
>>> -            goto out_destroy_policy;
>>>       }
>>>         if (cpufreq_driver->get && has_target()) {
>> Even if this change is required, I don't think this should be applied
>> separately. Just reverting this will get the bug back, which was fixed by
>> commit 1608f0230510. Individual patches shouldn't break kernel (and bisect) as
>> much as possible.
>>
> I could not reproduce the original issue.
> 
> At the time of the patch and still now, calls to
> freq_qos_update_request() are checked against negative values.
> The only exception is when using the scaling_max_frequency sysfs
> entry, but this is out of the scope.
> 
> So I don't see how:
> 
> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging a CPU")
> 
> can prevent a CPU to reach the boost frequency.  The only path that
> could fail and that I could reproduce was fixed by:
> 
> https://lore.kernel.org/all/852ff11c589e6300730d207baac195b2d9d8b95f.1745511526.git.viresh.kumar@linaro.org/
> 
> So the current conclusion is that "cpufreq: Fix re-boost issue after hotplugging a CPU"
> was not the real fix
> 
> 

Yes. After Viresh's patchset, the original issue was solved. So commit
1608f0230510 is not needed anymore and can be reverted.

Re: [PATCH v5 3/6] cpufreq: Centralize boost freq QoS requests

[Pierre Gondois]

On 3/13/26 10:22, Viresh Kumar wrote:
> On 25-02-26, 09:49, Pierre Gondois wrote:
>> policy_set_boost() calls the cpufreq set_boost callback.
>> Update the newly added boost_freq_req request from there:
>> - whenever boost is toggled
>> - to cover all possible paths
>>
>> Signed-off-by: Pierre Gondois<pierre.gondois@arm.com>
>> ---
>>   drivers/cpufreq/cpufreq.c | 13 +++++++++++--
>>   1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 50467b938668a..42de32488f422 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -603,10 +603,19 @@ static int policy_set_boost(struct cpufreq_policy *policy, bool enable)
>>   	policy->boost_enabled = enable;
>>   
>>   	ret = cpufreq_driver->set_boost(policy, enable);
>> -	if (ret)
>> +	if (ret) {
>>   		policy->boost_enabled = !policy->boost_enabled;
>> +		return ret;
>> +	}
>>   
>> -	return ret;
>> +	ret = freq_qos_update_request(policy->boost_freq_req, policy->cpuinfo.max_freq);
>> +	if (ret < 0) {
>> +		policy->boost_enabled = !policy->boost_enabled;
>> +		cpufreq_driver->set_boost(policy, policy->boost_enabled);
>> +		return ret;
>> +	}
>> +
>> +	return 0;
> This can be:
>
>          return ret;

Actually the caller expects 0 for success and
freq_qos_update_request() can return a positive value for success, so 
the code above should be used I think.

> and you can then drop 'return ret' from the if block.
>
> And yes, merge with prev patch as Rafael suggested.
>