[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZhbgwBBvh6ccdO7x@shell.armlinux.org.uk>
Date: Wed, 10 Apr 2024 19:56:00 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, linux-pm@...r.kernel.org,
loongarch@...ts.linux.dev, linux-acpi@...r.kernel.org,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-riscv@...ts.infradead.org, kvmarm@...ts.linux.dev,
x86@...nel.org, acpica-devel@...ts.linuxfoundation.org,
linux-csky@...r.kernel.org, linux-doc@...r.kernel.org,
linux-ia64@...r.kernel.org, linux-parisc@...r.kernel.org,
Salil Mehta <salil.mehta@...wei.com>,
Jean-Philippe Brucker <jean-philippe@...aro.org>,
jianyong.wu@....com, justin.he@....com,
James Morse <james.morse@....com>
Subject: Re: [PATCH RFC v4 02/15] ACPI: processor: Register all CPUs from
acpi_processor_get_info()
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!
Powered by blists - more mailing lists