kernel/linux.git/drivers/acpi/processor_perflib.c, branch v6.6.132

ACPI: processor: perflib: Move problematic pr->performance check

2025-08-28T14:28:12+00:00

commit d405ec23df13e6df599f5bd965a55d13420366b8 upstream. Commit d33bd88ac0eb ("ACPI: processor: perflib: Fix initial _PPC limit application") added a pr->performance check that prevents the frequency QoS request from being added when the given processor has no performance object. Unfortunately, this causes a WARN() in freq_qos_remove_request() to trigger on an attempt to take the given CPU offline later because the frequency QoS object has not been added for it due to the missing performance object. Address this by moving the pr->performance check before calling acpi_processor_get_platform_limit() so it only prevents a limit from being set for the CPU if the performance object is not present. This way, the frequency QoS request is added as it was before the above commit and it is present all the time along with the CPU's cpufreq policy regardless of whether or not the CPU is online. Fixes: d33bd88ac0eb ("ACPI: processor: perflib: Fix initial _PPC limit application") Tested-by: Rafael J. Wysocki Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2801421.mvXUDI8C0e@rafael.j.wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: processor: perflib: Fix initial _PPC limit application

2025-08-28T14:28:12+00:00

commit d33bd88ac0ebb49e7f7c8f29a8c7ee9eae85d765 upstream. If the BIOS sets a _PPC frequency limit upfront, it will fail to take effect due to a call ordering issue. Namely, freq_qos_update_request() is called before freq_qos_add_request() for the given request causing the constraint update to be ignored. The call sequence in question is as follows: cpufreq_policy_online() acpi_cpufreq_cpu_init() acpi_processor_register_performance() acpi_processor_get_performance_info() acpi_processor_get_platform_limit() freq_qos_update_request(&perflib_req) <- inactive QoS request blocking_notifier_call_chain(&cpufreq_policy_notifier_list, CPUFREQ_CREATE_POLICY) acpi_processor_notifier() acpi_processor_ppc_init() freq_qos_add_request(&perflib_req) <- QoS request activation Address this by adding an acpi_processor_get_platform_limit() call to acpi_processor_ppc_init(), after the perflib_req activation via freq_qos_add_request(), which causes the initial _PPC limit to be picked up as appropriate. However, also ensure that the _PPC limit will not be picked up in the cases when the cpufreq driver does not call acpi_processor_register_performance() by adding a pr->performance check to the related_cpus loop in acpi_processor_ppc_init(). Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier") Signed-off-by: Jiayi Li Link: https://patch.msgid.link/20250721032606.3459369-1-lijiayi@kylinos.cn [ rjw: Consolidate pr-related checks in acpi_processor_ppc_init() ] [ rjw: Subject and changelog adjustments ] Cc: 5.4+ # 5.4+: 2d8b39a62a5d ACPI: processor: Avoid NULL pointer dereferences at init time Cc: 5.4+ # 5.4+: 3000ce3c52f8 cpufreq: Use per-policy frequency QoS Cc: 5.4+ # 5.4+: a1bb46c36ce3 ACPI: processor: Add QoS requests for all CPUs Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: processor: perflib: Avoid updating frequency QoS unnecessarily

2022-12-30T18:10:02+00:00

Modify acpi_processor_get_platform_limit() to avoid updating its frequency QoS request when the _PPC return value has not changed by comparing that value to the previous _PPC return value stored in the performance_platform_limit field of the struct acpi_processor corresponding to the given CPU. While at it, do the _PPC return value check against the state count earlier, to avoid setting performance_platform_limit to an invalid value, and make acpi_processor_ppc_init() use FREQ_QOS_MAX_DEFAULT_VALUE as the "no limit" frequency QoS for consistency. Signed-off-by: Rafael J. Wysocki

ACPI: processor: perflib: Use the "no limit" frequency QoS

2022-12-30T18:10:02+00:00

When _PPC returns 0, it means that the CPU frequency is not limited by the platform firmware, so make acpi_processor_get_platform_limit() update the frequency QoS request used by it to "no limit" in that case. This addresses a problem with limiting CPU frequency artificially on some systems after CPU offline/online to the frequency that corresponds to the first entry in the _PSS return package. Reported-by: Pratyush Yadav Signed-off-by: Rafael J. Wysocki Reviewed-by: Pratyush Yadav Tested-by: Pratyush Yadav

ACPI: processor: perflib: Adjust acpi_processor_notify_smm() return value

2022-12-07T17:09:39+00:00

Avoid returning a confusing error code from acpi_processor_notify_smm() if it is called for the second time in the case when SMM notification regarding P-state control is not supported. Signed-off-by: Rafael J. Wysocki

ACPI: processor: perflib: Rearrange acpi_processor_notify_smm()

2022-12-07T17:09:39+00:00

Rearrange the code in acpi_processor_notify_smm() to consolidate error handling in it and improve the comments in there while at it. No expected functional impact. Signed-off-by: Rafael J. Wysocki

ACPI: processor: perflib: Rearrange unregistration routine

2022-12-07T17:09:39+00:00

Rearrange acpi_processor_unregister_performance() to follow a more common error handling pattern and drop a redundant "return" statement from the end of it. No expected functional impact. Signed-off-by: Rafael J. Wysocki

ACPI: processor: perflib: Drop redundant parentheses

2022-12-07T17:09:39+00:00

Drop some redundant parentheses and rearrange some checks using them in the ACPI processor performance library code for better code clarity. No expected functional impact. Signed-off-by: Rafael J. Wysocki

ACPI: processor: perflib: Adjust white space

2022-12-07T17:09:39+00:00

Some inconsistent usage of white space in the ACPI processor performance library code causes that code to be somewhat harder to read that it would have been otherwise, so adjust the white space in there to address that. No expected functional impact. Signed-off-by: Rafael J. Wysocki

ACPI: processor_perflib: Cleanup print messages

2021-06-07T13:36:46+00:00

The log messages in processor_perflib.c is not in consistency, we have some printk() calls with PREFIX, but some are not; we use pr_*() functions without prefix. So add pr_fmt() and unify them with pr_*() functions. While at it, fix some obvious coding style issues when going through the functions. Signed-off-by: Hanjun Guo Signed-off-by: Rafael J. Wysocki