linux-kernel - Re: [PATCH RFC v4 02/15] ACPI: processor: Register all CPUs from acpi_processor_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0gG0xLajHsWXVM+-V+fQZAudvojechUa-DzFgwCs2q8Dg@mail.gmail.com>
Date: Wed, 10 Apr 2024 21:08:06 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Jonathan Cameron <Jonathan.Cameron@...wei.com>, "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 8:56 PM Russell King (Oracle)
<linux@...linux.org.uk> 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).