Re: [PATCH RFC v4 02/15] ACPI: processor: Register all CPUs from acpi_processor_get_info()
From: "Rafael J. Wysocki" <rafael@kernel.org>
Date: 2024-02-15 19:22:41
Also in:
kvmarm, linux-acpi, linux-arch, linux-doc, linux-pm, linux-riscv, lkml, loongarch
On Wed, Jan 31, 2024 at 5:50 PM Russell King [off-list ref] wrote:
quoted hunk ↗ jump to hunk
From: James Morse <james.morse@arm.com> To allow ACPI to skip the call to arch_register_cpu() when the _STA value indicates the CPU can't be brought online right now, move the arch_register_cpu() call into acpi_processor_get_info(). Systems can still be booted with 'acpi=off', or not include an ACPI description at all. For these, the CPUs continue to be registered by cpu_dev_register_generic(). This moves the CPU register logic back to a subsys_initcall(), while the memory nodes will have been registered earlier. Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Gavin Shan <redacted> Tested-by: Miguel Luis <redacted> Tested-by: Vishnu Pajjuri <redacted> Tested-by: Jianyong Wu <redacted> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Russell King (Oracle) <redacted> --- Changes since RFC v2: * Fixup comment in acpi_processor_get_info() (Gavin Shan) * Add comment in cpu_dev_register_generic() (Gavin Shan) --- drivers/acpi/acpi_processor.c | 12 ++++++++++++ drivers/base/cpu.c | 6 +++++- 2 files changed, 17 insertions(+), 1 deletion(-)diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index cf7c1cca69dd..a68c475cdea5 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c@@ -314,6 +314,18 @@ static int acpi_processor_get_info(struct acpi_device *device) cpufreq_add_device("acpi-cpufreq"); } + /* + * Register CPUs that are present. get_cpu_device() is used to skip + * duplicate CPU descriptions from firmware. + */ + if (!invalid_logical_cpuid(pr->id) && cpu_present(pr->id) && + !get_cpu_device(pr->id)) { + int ret = arch_register_cpu(pr->id); + + if (ret) + return ret; + } + /* * Extra Processor objects may be enumerated on MP systems with * less than the max # of CPUs. They should be ignored _iff
This is interesting, because right below there is the following code:
if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) {
int ret = acpi_processor_hotadd_init(pr);
if (ret)
return ret;
}
and acpi_processor_hotadd_init() essentially calls arch_register_cpu()
with some extra things around it (more about that below).
I do realize that acpi_processor_hotadd_init() is defined under
CONFIG_ACPI_HOTPLUG_CPU, so for the sake of the argument let's
consider an architecture where CONFIG_ACPI_HOTPLUG_CPU is set.
So why are the two conditionals that almost contradict each other both
needed? It looks like the new code could be combined with
acpi_processor_hotadd_init() to do the right thing in all cases.
Now, acpi_processor_hotadd_init() does some extra things that look
like they should be done by the new code too.
1. It checks invalid_phys_cpuid() which appears to be a good idea to me.
2. It uses locking around arch_register_cpu() which doesn't seem
unreasonable either.
3. It calls acpi_map_cpu() and I'm not sure why this is not done by
the new code.
The only thing that can be dropped from it is the _STA check AFAICS,
because acpi_processor_add() won't even be called if the CPU is not
present (and not enabled after the first patch).
So why does the code not do 1 - 3 above?
quoted hunk ↗ jump to hunk
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c index 47de0f140ba6..13d052bf13f4 100644 --- a/drivers/base/cpu.c +++ b/drivers/base/cpu.c@@ -553,7 +553,11 @@ static void __init cpu_dev_register_generic(void) { int i, ret; - if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES)) + /* + * When ACPI is enabled, CPUs are registered via + * acpi_processor_get_info(). + */ + if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES) || !acpi_disabled) return;
Honestly, this looks like a quick hack to me and it absolutely requires an ACK from the x86 maintainers to go anywhere.
for_each_present_cpu(i) {
--_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel