Re: [PATCH v5 03/18] ACPI: processor: Register deferred CPUs from acpi_processor_get_info()

[Jonathan Cameron]

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