On Mon, Jan 22, 2024 at 6:44 PM Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > > On Mon, 18 Dec 2023 21:30:50 +0100 > "Rafael J. Wysocki" <rafael@xxxxxxxxxx> wrote: > > > On Wed, Dec 13, 2023 at 1:49 PM Russell King <rmk+kernel@xxxxxxxxxxxxxxx> wrote: > > > > > > From: James Morse <james.morse@xxxxxxx> > > > > > > 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(). > > > > This kind of looks backwards to me and has a potential to become > > super-confusing. > > > > I would instead add a way for the generic code to ask the platform > > firmware whether or not the given CPU is enabled and so it can be > > registered. > > Hi Rafael, > > The ACPI interpreter isn't up at this stage so we'd need to pull that > forwards. I'm not sure if we can pull the interpreter init early enough. Well, this patch effectively defers the AP registration to the time when acpi_processor_get_info() runs and the interpreter is up and running then. For consistency, it would be better to defer the AP registration in general to that point. > Perhaps pushing the registration back in all cases is the way to go? > Given the acpi interpretter is initialized via subsys_initcall() it would > need to be after that - I tried pushing cpu_dev_register_generic() > immediately after acpi_bus_init() and that seems fine. Sounds promising. > We can't leave the rest of cpu_dev_init() that late because a bunch > of other stuff relies on it (CPU freq blows up first as a core_init() > on my setup). I see. > So to make this work we need it to always move the registration later > than the necessary infrastructure, perhaps to subsys_initcall_sync() > as is done for missing CPUs (we'd need to combine the two given that > needs to run after this, or potentially just stop checking for acpi_disabled > and don't taint the kernel!). I think this is probably the most consistent > option on basis it at least moves the registration to the same point > whatever is going on and can easily use the arch callback you suggest > to hide away the logic on deciding if a CPU is there or not. I agree.
