On Wed, 10 Apr 2024 21:08:06 +0200 "Rafael J. Wysocki" <rafael@xxxxxxxxxx> wrote: > On Wed, Apr 10, 2024 at 8:56 PM Russell King (Oracle) > <linux@xxxxxxxxxxxxxxx> wrote: > > > > On Wed, Apr 10, 2024 at 02:50:05PM +0100, Jonathan Cameron wrote: > > > If we get rid of this catch all, solution would be to move the > > > !acpi_disabled check into the arm64 version of arch_cpu_register() > > > because we would only want the delayed registration path to be > > > used on ACPI cases where the question of CPU availability can't > > > yet be resolved. > > > > Aren't we then needing two arch_register_cpu() implementations? > > I'm assuming that you're suggesting that the !acpi_disabled, then > > do nothing check is moved into arch_register_cpu() - or to put it > > another way, arch_register_cpu() does nothing if ACPI is enabled. > > > > If arch_register_cpu() does nothing if ACPI is enabled, how do > > CPUs get registered (and sysfs files get created to control them) > > on ACPI systems? ACPI wouldn't be able to call arch_register_cpu(), > > so I suspect you'll need an ACPI-specific version of this function. > > arch_register_cpu() will do what it does, but it will check (upfront) > if ACPI is enabled and if so, if the ACPI Namespace is available. In > the case when ACPI is enabled and the ACPI Namespace is not ready, it > will return -EPROBE_DEFER (say). Exactly. I oversimplified and wasn't clear enough. The check is there in the arch_register_cpu() and is one of the ways that function can decide to actually register the cpu but not the only one. I think we may later want to consider breaking it into 2 arch calls (check if ready to register + register) to reduce code duplication in with the hotplug path where there is a little extra to do inbetween. Hopefully that can wait though. Jonathan
