linux-toradex.git/drivers/acpi/processor_driver.c, branch v6.19

Revert "ACPI: processor: Update cpuidle driver check in __acpi_processor_start()"

2025-11-27T19:52:55+00:00

Revert commit 8a1b5d412cb4 ("ACPI: processor: Update cpuidle driver
check in __acpi_processor_start()") which depends on commit
7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver
registration") that got reverted.

Signed-off-by: Rafael J. Wysocki

Revert "ACPI: processor: idle: Optimize ACPI idle driver registration"

2025-11-25T15:08:06+00:00

Revert commit 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle
driver registration") because it is reported to introduce a cpuidle
regression leading to a kernel crash on a platform using the ACPI idle
driver.

Signed-off-by: Rafael J. Wysocki 
Reported-by: Borislav Petkov 
Tested-by: Borislav Petkov (AMD) 
Closes: https://lore.kernel.org/lkml/20251124200019.GIaSS5U9HhsWBotrQZ@fat_crate.local/

Revert "ACPI: processor: Do not expose global variable acpi_idle_driver"

2025-11-25T13:50:25+00:00

Revert commit 559f2eacc8a2 ACPI: processor: Do not expose global variable
acpi_idle_driver" because it depends on a problematic one.

Signed-off-by: Rafael J. Wysocki

ACPI: processor: Do not expose global variable acpi_idle_driver

2025-09-23T13:33:19+00:00

Move the cpuidle driver check from __acpi_processor_start() to
acpi_processor_power_init() which allows variable acpi_idle_driver to
become static.

No intentional functional impact.

Signed-off-by: Huisong Li 
Link: https://patch.msgid.link/20250923032428.2656329-2-lihuisong@huawei.com
[ rjw: Subject tweak, new changelog, adjustment of a new comment ]
Signed-off-by: Rafael J. Wysocki

ACPI: processor: Update cpuidle driver check in __acpi_processor_start()

2025-09-19T20:49:49+00:00

Commit 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle
driver registration") moved the ACPI idle driver registration to
acpi_processor_driver_init() and acpi_processor_power_init() does
not register an idle driver any more.

Accordingly, the cpuidle driver check in __acpi_processor_start() needs
to be updated to avoid calling acpi_processor_power_init() without a
cpuidle driver, in which case the registration of the cpuidle device
in that function would lead to a NULL pointer dereference in
__cpuidle_register_device().

Fixes: 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration")
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mario Limonciello (AMD) 
Link: https://patch.msgid.link/5044465.31r3eYUQgx@rafael.j.wysocki
[ rjw: Changelog update ]
Signed-off-by: Rafael J. Wysocki

ACPI: processor: idle: Optimize ACPI idle driver registration

2025-09-02T14:08:25+00:00

Currently, the ACPI idle driver is registered from within a CPU
hotplug callback. Although this didn't cause any functional issues,
this is questionable and confusing. And it is better to register
the cpuidle driver when all of the CPUs have been brought up.

So add a new function to initialize acpi_idle_driver based on the
power management information of an available CPU and register cpuidle
driver in acpi_processor_driver_init().

Signed-off-by: Huisong Li 
Link: https://patch.msgid.link/20250728070612.1260859-3-lihuisong@huawei.com
[ rjw: Added missing inline modifiers ]
Signed-off-by: Rafael J. Wysocki

ACPI: processor: Rescan "dead" SMT siblings during initialization

2025-06-07T12:23:22+00:00

Make acpi_processor_driver_init() call arch_cpu_rescan_dead_smt_siblings(),
via a new wrapper function called acpi_idle_rescan_dead_smt_siblings(),
after successfully initializing the driver, to allow the "dead" SMT
siblings to go into deep idle states, which is necessary for the
processor to be able to reach deep package C-states (like PC10) going
forward, so that power can be reduced sufficiently in suspend-to-idle,
among other things.

However, do it only if the ACPI idle driver is the current cpuidle
driver (otherwise it is assumed that another cpuidle driver will take
care of this) and avoid doing it on architectures other than x86.

Signed-off-by: Rafael J. Wysocki 
Tested-by: Artem Bityutskiy 
Link: https://patch.msgid.link/2005721.PYKUYFuaPT@rjwysocki.net

ACPI: processor: Move arch_init_invariance_cppc() call later

2024-11-06T20:31:36+00:00

arch_init_invariance_cppc() is called at the end of
acpi_cppc_processor_probe() in order to configure frequency invariance
based upon the values from _CPC.

This however doesn't work on AMD CPPC shared memory designs that have
AMD preferred cores enabled because _CPC needs to be analyzed from all
cores to judge if preferred cores are enabled.

This issue manifests to users as a warning since commit 21fb59ab4b97
("ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn"):
```
Could not retrieve highest performance (-19)
```

However the warning isn't the cause of this, it was actually
commit 279f838a61f9 ("x86/amd: Detect preferred cores in
amd_get_boost_ratio_numerator()") which exposed the issue.

To fix this problem, change arch_init_invariance_cppc() into a new weak
symbol that is called at the end of acpi_processor_driver_init().
Each architecture that supports it can declare the symbol to override
the weak one.

Define it for x86, in arch/x86/kernel/acpi/cppc.c, and for all of the
architectures using the generic arch_topology.c code.

Fixes: 279f838a61f9 ("x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()")
Reported-by: Ivan Shapovalov 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219431
Tested-by: Oleksandr Natalenko 
Signed-off-by: Mario Limonciello 
Link: https://patch.msgid.link/20241104222855.3959267-1-superm1@kernel.org
[ rjw: Changelog edit ]
Signed-off-by: Rafael J. Wysocki

ACPI: processor: Simplify initial onlining to use same path for cold and hotplug

2024-06-28T17:38:27+00:00

Separate code paths, combined with a flag set in acpi_processor.c to
indicate a struct acpi_processor was for a hotplugged CPU ensured that
per CPU data was only set up the first time that a CPU was initialized.
This appears to be unnecessary as the paths can be combined by letting
the online logic also handle any CPUs online at the time of driver load.

Motivation for this change, beyond simplification, is that ARM64
virtual CPU HP uses the same code paths for hotplug and cold path in
acpi_processor.c so had no easy way to set the flag for hotplug only.
Removing this necessity will enable ARM64 vCPU HP to reuse the existing
code paths.

Acked-by: Rafael J. Wysocki 
Reviewed-by: Hanjun Guo 
Tested-by: Miguel Luis 
Reviewed-by: Gavin Shan 
Reviewed-by: Miguel Luis 
Signed-off-by: Jonathan Cameron 
Link: https://lore.kernel.org/r/20240529133446.28446-2-Jonathan.Cameron@huawei.com
Signed-off-by: Catalin Marinas

ACPI: cpufreq: Add highest perf change notification

2024-01-31T13:54:50+00:00

Platform firmware sends notify 0x85 to inform the OS that the highest
performance of a CPU has changed.

This will be used by the AMD P-state driver to update the ranking of
preferred cores and set the priority of cores accordingly.

Tested-by: Oleksandr Natalenko 
Reviewed-by: Mario Limonciello 
Reviewed-by: Huang Rui 
Reviewed-by: Perry Yuan 
Signed-off-by: Meng Li 
Link: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#processor-device-notification-values
[ rjw: New subject, changelog edits ]
Signed-off-by: Rafael J. Wysocki