Messages in this thread Patch in this message | | | From | "Rafael J. Wysocki" <> | Date | Thu, 15 Feb 2024 20:22:29 +0100 | Subject | Re: [PATCH RFC v4 02/15] ACPI: processor: Register all CPUs from acpi_processor_get_info() |
| |
On Wed, Jan 31, 2024 at 5:50 PM Russell King <rmk+kernel@armlinux.org.uk> wrote: > > 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 <gshan@redhat.com> > Tested-by: Miguel Luis <miguel.luis@oracle.com> > Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com> > Tested-by: Jianyong Wu <jianyong.wu@arm.com> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > 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?
> 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) { > --
| |