Re: [PATCH RFC v4 02/15] ACPI: processor: Register all CPUs from acpi_processor_get_info()
"Russell King (Oracle)" <[email protected]> Wed, 10 Apr 2024 19:56:00 +0100
| Newsgroups | org.kernel.vger.linux-ia64,dev.linux.lists.acpica-devel,dev.linux.lists.kvmarm,dev.linux.lists.loongarch,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.linux-acpi,org.kernel.vger.linux-arch,org.kernel.vger.linux-csky,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-parisc,org.kernel.vger.linux-pm |
|---|---|
| Message-ID | <[email protected]> |
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. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!