policy->max_freq_req QoS constraint represents the maximal allowed
frequency than can be requested. It is set by:
- writing to policyX/scaling_max sysfs file
- toggling the cpufreq/boost sysfs file

Upon calling freq_qos_update_request(), a successful update
of the max_freq_req value triggers cpufreq_notifier_max(),
followed by cpufreq_set_policy() which update the requested
frequency for the policy.
If the new max_freq_req value is not different from the
original value, no frequency update is triggered.

In a specific sequence of toggling:
- cpufreq/boost sysfs file
- CPU hot-plugging
a CPU could end up with boost enabled but running at the
maximal non-boost frequency, cpufreq_notifier_max() not being
triggered. The following fixed that:
commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
a CPU")

The following:
commit dd016f379ebc ("cpufreq: Introduce a more generic way to
set default per-policy boost flag")
also fixed the issue by correctly setting the max_freq_req
constraint of a policy that is re-activated. This makes the
first fix unnecessary.

As the original issue is fixed by another method,
this patch reverts:
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 277884d91913c..5757f12633d16 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1487,10 +1487,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

What do you mean by per-CPU QOS constraint in Subject ? This is per-policy
constraint and you are not removing it, you are just avoiding to update it in
one of the paths.

On 25-03-26, 17:52, Pierre Gondois wrote:
> policy->max_freq_req QoS constraint represents the maximal allowed
> frequency than can be requested. It is set by:
> - writing to policyX/scaling_max sysfs file
> - toggling the cpufreq/boost sysfs file
> 
> Upon calling freq_qos_update_request(), a successful update
> of the max_freq_req value triggers cpufreq_notifier_max(),
> followed by cpufreq_set_policy() which update the requested
> frequency for the policy.
> If the new max_freq_req value is not different from the
> original value, no frequency update is triggered.
> 
> In a specific sequence of toggling:
> - cpufreq/boost sysfs file
> - CPU hot-plugging
> a CPU could end up with boost enabled but running at the
> maximal non-boost frequency, cpufreq_notifier_max() not being
> triggered. The following fixed that:
> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
> a CPU")
> 
> The following:
> commit dd016f379ebc ("cpufreq: Introduce a more generic way to
> set default per-policy boost flag")
> also fixed the issue by correctly setting the max_freq_req
> constraint of a policy that is re-activated. This makes the
> first fix unnecessary.
> 
> As the original issue is fixed by another method,
> this patch reverts:
> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
> a CPU")

Looks okay otherwise.

-- 
viresh

On 3/26/26 05:37, Viresh Kumar wrote:
> What do you mean by per-CPU QOS constraint in Subject ? This is per-policy
> constraint and you are not removing it, you are just avoiding to update it in
> one of the paths.
Right, I ll update the patch header
> On 25-03-26, 17:52, Pierre Gondois wrote:
>> policy->max_freq_req QoS constraint represents the maximal allowed
>> frequency than can be requested. It is set by:
>> - writing to policyX/scaling_max sysfs file
>> - toggling the cpufreq/boost sysfs file
>>
>> Upon calling freq_qos_update_request(), a successful update
>> of the max_freq_req value triggers cpufreq_notifier_max(),
>> followed by cpufreq_set_policy() which update the requested
>> frequency for the policy.
>> If the new max_freq_req value is not different from the
>> original value, no frequency update is triggered.
>>
>> In a specific sequence of toggling:
>> - cpufreq/boost sysfs file
>> - CPU hot-plugging
>> a CPU could end up with boost enabled but running at the
>> maximal non-boost frequency, cpufreq_notifier_max() not being
>> triggered. The following fixed that:
>> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
>> a CPU")
>>
>> The following:
>> commit dd016f379ebc ("cpufreq: Introduce a more generic way to
>> set default per-policy boost flag")
>> also fixed the issue by correctly setting the max_freq_req
>> constraint of a policy that is re-activated. This makes the
>> first fix unnecessary.
>>
>> As the original issue is fixed by another method,
>> this patch reverts:
>> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
>> a CPU")
> Looks okay otherwise.
>