[PATCH] ACPI: Fix initial QoS constraint application order in PPC initialization

[PATCH] ACPI: Fix initial QoS constraint application order in PPC initialization

[Jiayi Li]

The original initialization sequence was:

cpufreq_policy_online()
    acpi_cpufreq_cpu_init()
        acpi_processor_get_platform_limit()
            freq_qos_update_request(&perflib_req)
    blocking_notifier_call_chain(...)
        acpi_processor_ppc_init()
            freq_qos_add_request(&perflib_req)

This caused a race condition where the QoS request was added after the
initial platform limit update. The new sequence explicitly ensures:

cpufreq_policy_online()
    acpi_cpufreq_cpu_init()
        acpi_processor_get_platform_limit()
            freq_qos_update_request(&perflib_req)
    blocking_notifier_call_chain(...)
        acpi_processor_ppc_init()
            freq_qos_add_request(&perflib_req)
+           acpi_processor_get_platform_limit()
+               freq_qos_update_request(&perflib_req)

The critical change adds an immediate platform limit update after the
QoS request is registered. This guarantees that the initial P-state
constraint is applied before any subsequent updates, resolving the window
where constraints could be applied out-of-order.

Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier")
Signed-off-by: Jiayi Li <lijiayi@kylinos.cn>
---
 drivers/acpi/processor_perflib.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 64b8d1e19594..3e7fe95c21d1 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -173,6 +173,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
 {
 	unsigned int cpu;
 
+	if (ignore_ppc == 1)
+		return;
+
 	for_each_cpu(cpu, policy->related_cpus) {
 		struct acpi_processor *pr = per_cpu(processors, cpu);
 		int ret;
@@ -193,6 +196,11 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
 		if (ret < 0)
 			pr_err("Failed to add freq constraint for CPU%d (%d)\n",
 			       cpu, ret);
+
+		ret = acpi_processor_get_platform_limit(pr);
+		if (ret)
+			pr_err("Failed to update freq constraint for CPU%d (%d)\n",
+			       cpu, ret);
 	}
 }
 
-- 
2.47.1

Re: [PATCH] ACPI: Fix initial QoS constraint application order in PPC initialization

[Rafael J. Wysocki]

On Fri, Jul 18, 2025 at 4:03 AM Jiayi Li <lijiayi@kylinos.cn> wrote:
>
> The original initialization sequence was:
>
> cpufreq_policy_online()
>     acpi_cpufreq_cpu_init()
>         acpi_processor_get_platform_limit()
>             freq_qos_update_request(&perflib_req)
>     blocking_notifier_call_chain(...)
>         acpi_processor_ppc_init()
>             freq_qos_add_request(&perflib_req)
>
> This caused a race condition where the QoS request was added after the
> initial platform limit update.

To me, the description above is useless for figuring out what's going on, sorry.

This is not a race, but an ordering issue.

The cpufreq driver calls acpi_processor_register_performance(), which
among other things causes acpi_processor_get_platform_limit() to be
called, from its ->init() callback which is invoked by the cpufreq
core before CPUFREQ_CREATE_POLICY notifiers and the policy frequency
QoS requests are added by acpi_processor_notifier(), so they don't
exist when acpi_processor_register_performance() gets called and they
cannot be updated by the acpi_processor_get_platform_limit().

You want them to be updated as soon as they have been added, which is
kind of reasonable, but it needs to be done only if
acpi_processor_register_performance() has been called by the cpufreq
driver.

> The new sequence explicitly ensures:
>
> cpufreq_policy_online()
>     acpi_cpufreq_cpu_init()
>         acpi_processor_get_platform_limit()
>             freq_qos_update_request(&perflib_req)
>     blocking_notifier_call_chain(...)
>         acpi_processor_ppc_init()
>             freq_qos_add_request(&perflib_req)
> +           acpi_processor_get_platform_limit()
> +               freq_qos_update_request(&perflib_req)
>
> The critical change adds an immediate platform limit update after the
> QoS request is registered. This guarantees that the initial P-state
> constraint is applied before any subsequent updates, resolving the window
> where constraints could be applied out-of-order.
>
> Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier")
> Signed-off-by: Jiayi Li <lijiayi@kylinos.cn>
> ---
>  drivers/acpi/processor_perflib.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
> index 64b8d1e19594..3e7fe95c21d1 100644
> --- a/drivers/acpi/processor_perflib.c
> +++ b/drivers/acpi/processor_perflib.c
> @@ -173,6 +173,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
>  {
>         unsigned int cpu;
>
> +       if (ignore_ppc == 1)
> +               return;
> +
>         for_each_cpu(cpu, policy->related_cpus) {
>                 struct acpi_processor *pr = per_cpu(processors, cpu);
>                 int ret;

So AFAICS  this loop needs to check pr->performance in addition to pr.

> @@ -193,6 +196,11 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
>                 if (ret < 0)
>                         pr_err("Failed to add freq constraint for CPU%d (%d)\n",
>                                cpu, ret);
> +
> +               ret = acpi_processor_get_platform_limit(pr);
> +               if (ret)
> +                       pr_err("Failed to update freq constraint for CPU%d (%d)\n",
> +                              cpu, ret);
>         }
>  }
>
> --

Re: [PATCH] ACPI: Fix initial QoS constraint application order in PPC initialization

[Jiayi Li]

>>
>> The original initialization sequence was:
>>
>> cpufreq_policy_online()
>>     acpi_cpufreq_cpu_init()
>>         acpi_processor_get_platform_limit()
>>             freq_qos_update_request(&perflib_req)
>>     blocking_notifier_call_chain(...)
>>         acpi_processor_ppc_init()
>>             freq_qos_add_request(&perflib_req)
>>
>> This caused a race condition where the QoS request was added after the
>> initial platform limit update.
>
>To me, the description above is useless for figuring out what's going on, sorry.
>
>This is not a race, but an ordering issue.
>
>The cpufreq driver calls acpi_processor_register_performance(), which
>among other things causes acpi_processor_get_platform_limit() to be
>called, from its ->init() callback which is invoked by the cpufreq
>core before CPUFREQ_CREATE_POLICY notifiers and the policy frequency
>QoS requests are added by acpi_processor_notifier(), so they don't
>exist when acpi_processor_register_performance() gets called and they
>cannot be updated by the acpi_processor_get_platform_limit().
>
>You want them to be updated as soon as they have been added, which is
>kind of reasonable, but it needs to be done only if
>acpi_processor_register_performance() has been called by the cpufreq
>driver.
>

Sorry, I didn't make the question clear.

This patch fixes an issue where _PPC frequency limits set by the BIOS
failed to take effect due to incorrect call ordering. Previously,
freq_qos_update_request() was being called before freq_qos_add_request(),
causing the constraint updates to be ignored. With this fix, the frequency
limits are now properly enforced as intended.

>> The new sequence explicitly ensures:
>>
>> cpufreq_policy_online()
>>     acpi_cpufreq_cpu_init()
>>         acpi_processor_get_platform_limit()
>>             freq_qos_update_request(&perflib_req)
>>     blocking_notifier_call_chain(...)
>>         acpi_processor_ppc_init()
>>             freq_qos_add_request(&perflib_req)
>> +           acpi_processor_get_platform_limit()
>> +               freq_qos_update_request(&perflib_req)
>>
>> The critical change adds an immediate platform limit update after the
>> QoS request is registered. This guarantees that the initial P-state
>> constraint is applied before any subsequent updates, resolving the window
>> where constraints could be applied out-of-order.
>>
>> Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier")
>> Signed-off-by: Jiayi Li <lijiayi@kylinos.cn>
>> ---
>>  drivers/acpi/processor_perflib.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
>> index 64b8d1e19594..3e7fe95c21d1 100644
>> --- a/drivers/acpi/processor_perflib.c
>> +++ b/drivers/acpi/processor_perflib.c
>> @@ -173,6 +173,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
>>  {
>>         unsigned int cpu;
>>
>> +       if (ignore_ppc == 1)
>> +               return;
>> +
>>         for_each_cpu(cpu, policy->related_cpus) {
>>                 struct acpi_processor *pr = per_cpu(processors, cpu);
>>                 int ret;
>
>So AFAICS  this loop needs to check pr->performance in addition to pr.
>

Thanks for the review. I agree and will add a check for pr->performance in v2.

--
lijiayi

[PATCH v2] ACPI: Fix initial QoS constraint application order in PPC initialization

[Jiayi Li]

This patch fixes an issue where _PPC frequency limits set by the BIOS
failed to take effect due to incorrect call ordering. Previously,
freq_qos_update_request() was being called before freq_qos_add_request(),
causing the constraint updates to be ignored. With this fix, the frequency
limits are now properly enforced as intended.
The original initialization sequence was:

cpufreq_policy_online()
    acpi_cpufreq_cpu_init()
        acpi_processor_get_platform_limit()
            freq_qos_update_request(&perflib_req)
    blocking_notifier_call_chain(...)
        acpi_processor_ppc_init()
            freq_qos_add_request(&perflib_req)

The new sequence explicitly ensures:

cpufreq_policy_online()
    acpi_cpufreq_cpu_init()
        acpi_processor_get_platform_limit()
            freq_qos_update_request(&perflib_req)
    blocking_notifier_call_chain(...)
        acpi_processor_ppc_init()
            freq_qos_add_request(&perflib_req)
+           acpi_processor_get_platform_limit()
+               freq_qos_update_request(&perflib_req)

The critical change adds an immediate platform limit update after the
QoS request is registered. This guarantees that the initial P-state
constraint is applied before any subsequent updates, resolving the window
where constraints could be applied out-of-order.

Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier")
Signed-off-by: Jiayi Li <lijiayi@kylinos.cn>
---
v1 -> v2:
- Modify the commit.
- Add pr->performance check in acpi_processor_ppc_init loop.
---
---
 drivers/acpi/processor_perflib.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 64b8d1e19594..56f2b8354d62 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -173,6 +173,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
 {
 	unsigned int cpu;
 
+	if (ignore_ppc == 1)
+		return;
+
 	for_each_cpu(cpu, policy->related_cpus) {
 		struct acpi_processor *pr = per_cpu(processors, cpu);
 		int ret;
@@ -180,6 +183,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
 		if (!pr)
 			continue;
 
+		if (!pr->performance)
+			continue;
+
 		/*
 		 * Reset performance_platform_limit in case there is a stale
 		 * value in it, so as to make it match the "no limit" QoS value
@@ -193,6 +199,11 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
 		if (ret < 0)
 			pr_err("Failed to add freq constraint for CPU%d (%d)\n",
 			       cpu, ret);
+
+		ret = acpi_processor_get_platform_limit(pr);
+		if (ret)
+			pr_err("Failed to update freq constraint for CPU%d (%d)\n",
+			       cpu, ret);
 	}
 }
 
-- 
2.47.1

Re: [PATCH v2] ACPI: Fix initial QoS constraint application order in PPC initialization

[Rafael J. Wysocki]

On Mon, Jul 21, 2025 at 5:26 AM Jiayi Li <lijiayi@kylinos.cn> wrote:
>
> This patch fixes an issue where _PPC frequency limits set by the BIOS
> failed to take effect due to incorrect call ordering. Previously,
> freq_qos_update_request() was being called before freq_qos_add_request(),
> causing the constraint updates to be ignored. With this fix, the frequency
> limits are now properly enforced as intended.
> The original initialization sequence was:
>
> cpufreq_policy_online()
>     acpi_cpufreq_cpu_init()
>         acpi_processor_get_platform_limit()
>             freq_qos_update_request(&perflib_req)
>     blocking_notifier_call_chain(...)
>         acpi_processor_ppc_init()
>             freq_qos_add_request(&perflib_req)
>
> The new sequence explicitly ensures:
>
> cpufreq_policy_online()
>     acpi_cpufreq_cpu_init()
>         acpi_processor_get_platform_limit()
>             freq_qos_update_request(&perflib_req)
>     blocking_notifier_call_chain(...)
>         acpi_processor_ppc_init()
>             freq_qos_add_request(&perflib_req)
> +           acpi_processor_get_platform_limit()
> +               freq_qos_update_request(&perflib_req)
>
> The critical change adds an immediate platform limit update after the
> QoS request is registered. This guarantees that the initial P-state
> constraint is applied before any subsequent updates, resolving the window
> where constraints could be applied out-of-order.
>
> Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier")
> Signed-off-by: Jiayi Li <lijiayi@kylinos.cn>
> ---
> v1 -> v2:
> - Modify the commit.
> - Add pr->performance check in acpi_processor_ppc_init loop.
> ---
> ---
>  drivers/acpi/processor_perflib.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
> index 64b8d1e19594..56f2b8354d62 100644
> --- a/drivers/acpi/processor_perflib.c
> +++ b/drivers/acpi/processor_perflib.c
> @@ -173,6 +173,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
>  {
>         unsigned int cpu;
>
> +       if (ignore_ppc == 1)
> +               return;
> +
>         for_each_cpu(cpu, policy->related_cpus) {
>                 struct acpi_processor *pr = per_cpu(processors, cpu);
>                 int ret;
> @@ -180,6 +183,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
>                 if (!pr)
>                         continue;
>
> +               if (!pr->performance)
> +                       continue;
> +
>                 /*
>                  * Reset performance_platform_limit in case there is a stale
>                  * value in it, so as to make it match the "no limit" QoS value

Applied, but I have consolidated the pr and pr->performance checks above.

I have also made some changes in the subject and changelog.

Thanks!

> @@ -193,6 +199,11 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
>                 if (ret < 0)
>                         pr_err("Failed to add freq constraint for CPU%d (%d)\n",
>                                cpu, ret);
> +
> +               ret = acpi_processor_get_platform_limit(pr);
> +               if (ret)
> +                       pr_err("Failed to update freq constraint for CPU%d (%d)\n",
> +                              cpu, ret);
>         }
>  }
>
> --

Re: [PATCH v2] ACPI: Fix initial QoS constraint application order in PPC initialization

[李佳怡]

在 2025/7/21 21:27, Rafael J. Wysocki 写道:
> On Mon, Jul 21, 2025 at 5:26 AM Jiayi Li <lijiayi@kylinos.cn> wrote:
>>
>> This patch fixes an issue where _PPC frequency limits set by the BIOS
>> failed to take effect due to incorrect call ordering. Previously,
>> freq_qos_update_request() was being called before freq_qos_add_request(),
>> causing the constraint updates to be ignored. With this fix, the frequency
>> limits are now properly enforced as intended.
>> The original initialization sequence was:
>>
>> cpufreq_policy_online()
>>      acpi_cpufreq_cpu_init()
>>          acpi_processor_get_platform_limit()
>>              freq_qos_update_request(&perflib_req)
>>      blocking_notifier_call_chain(...)
>>          acpi_processor_ppc_init()
>>              freq_qos_add_request(&perflib_req)
>>
>> The new sequence explicitly ensures:
>>
>> cpufreq_policy_online()
>>      acpi_cpufreq_cpu_init()
>>          acpi_processor_get_platform_limit()
>>              freq_qos_update_request(&perflib_req)
>>      blocking_notifier_call_chain(...)
>>          acpi_processor_ppc_init()
>>              freq_qos_add_request(&perflib_req)
>> +           acpi_processor_get_platform_limit()
>> +               freq_qos_update_request(&perflib_req)
>>
>> The critical change adds an immediate platform limit update after the
>> QoS request is registered. This guarantees that the initial P-state
>> constraint is applied before any subsequent updates, resolving the window
>> where constraints could be applied out-of-order.
>>
>> Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier")
>> Signed-off-by: Jiayi Li <lijiayi@kylinos.cn>
>> ---
>> v1 -> v2:
>> - Modify the commit.
>> - Add pr->performance check in acpi_processor_ppc_init loop.
>> ---
>> ---
>>   drivers/acpi/processor_perflib.c | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
>> index 64b8d1e19594..56f2b8354d62 100644
>> --- a/drivers/acpi/processor_perflib.c
>> +++ b/drivers/acpi/processor_perflib.c
>> @@ -173,6 +173,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
>>   {
>>          unsigned int cpu;
>>
>> +       if (ignore_ppc == 1)
>> +               return;
>> +
>>          for_each_cpu(cpu, policy->related_cpus) {
>>                  struct acpi_processor *pr = per_cpu(processors, cpu);
>>                  int ret;
>> @@ -180,6 +183,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
>>                  if (!pr)
>>                          continue;
>>
>> +               if (!pr->performance)
>> +                       continue;
>> +
>>                  /*
>>                   * Reset performance_platform_limit in case there is a stale
>>                   * value in it, so as to make it match the "no limit" QoS value
> 
> Applied, but I have consolidated the pr and pr->performance checks above.
> 
> I have also made some changes in the subject and changelog.
> 
> Thanks!

Thanks for the review!

> 
>> @@ -193,6 +199,11 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
>>                  if (ret < 0)
>>                          pr_err("Failed to add freq constraint for CPU%d (%d)\n",
>>                                 cpu, ret);
>> +
>> +               ret = acpi_processor_get_platform_limit(pr);
>> +               if (ret)
>> +                       pr_err("Failed to update freq constraint for CPU%d (%d)\n",
>> +                              cpu, ret);
>>          }
>>   }
>>
>> --