On Fri, 12 Apr 2024 15:37:04 +0100 Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > From: James Morse <james.morse@xxxxxxx> > > The arm64 specific arch_register_cpu() call may defer CPU registration > until the ACPI interpreter is available and the _STA method can > be evaluated. > > If this occurs, then a second attempt is made in > acpi_processor_get_info(). Note that the arm64 specific call has > not yet been added so for now this will never be successfully > called. > > Systems can still be booted with 'acpi=off', or not include an > ACPI description at all as in these cases arch_register_cpu() > will not have deferred registration when first called. > > This moves the CPU register logic back to a subsys_initcall(), > while the memory nodes will have been registered earlier. > Note this is where the call was prior to the cleanup series so > there should be no side effects of moving it back again for this > specific case. > > [PATCH 00/21] Initial cleanups for vCPU HP. > https://lore.kernel.org/all/ZVyz%2FVe5pPu8AWoA@xxxxxxxxxxxxxxxxxxxxx/ > > e.g. 5b95f94c3b9f ("x86/topology: Switch over to GENERIC_CPU_DEVICES") > > Signed-off-by: James Morse <james.morse@xxxxxxx> > Reviewed-by: Gavin Shan <gshan@xxxxxxxxxx> > Tested-by: Miguel Luis <miguel.luis@xxxxxxxxxx> > Tested-by: Vishnu Pajjuri <vishnu@xxxxxxxxxxxxxxxxxxxxxx> > Tested-by: Jianyong Wu <jianyong.wu@xxxxxxx> > Signed-off-by: Russell King (Oracle) <rmk+kernel@xxxxxxxxxxxxxxx> > Co-developed-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> > Signed-off-by: Joanthan Cameron <Jonathan.Cameron@xxxxxxxxxx> > --- > v5: Update commit message to make it clear this is moving the > init back to where it was until very recently. > > No longer change the condition in the earlier registration point > as that will be handled by the arm64 registration routine > deferring until called again here. > --- > drivers/acpi/acpi_processor.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c > index 93e029403d05..c78398cdd060 100644 > --- a/drivers/acpi/acpi_processor.c > +++ b/drivers/acpi/acpi_processor.c > @@ -317,6 +317,18 @@ static int acpi_processor_get_info(struct acpi_device *device) > > c = &per_cpu(cpu_devices, pr->id); > ACPI_COMPANION_SET(&c->dev, device); > + /* > + * 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)) { Just a quick note to call out that this case of 'duplicate' firmware description needs an updated comment. Now we are not deferring registration on x86 this is detecting that arch_register_cpu() has already been successfully called and we should not do it again. I've added rather more detailed comments enumerating of the paths we can take to hit acpi_processor_hotadd_init() in the v6 series (tests ongoing) Jonathan > + 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
