On Tue, 2 Jan 2024 14:53:20 +0000 Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > On Mon, 18 Dec 2023 13:03:32 +0000 > "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx> wrote: > > > On Wed, Dec 13, 2023 at 12:50:38PM +0000, Russell King wrote: > > > From: James Morse <james.morse@xxxxxxx> > > > > > > acpi_processor_get_info() registers all present CPUs. Registering a > > > CPU is what creates the sysfs entries and triggers the udev > > > notifications. > > > > > > arm64 virtual machines that support 'virtual cpu hotplug' use the > > > enabled bit to indicate whether the CPU can be brought online, as > > > the existing ACPI tables require all hardware to be described and > > > present. > > > > > > If firmware describes a CPU as present, but disabled, skip the > > > registration. Such CPUs are present, but can't be brought online for > > > whatever reason. (e.g. firmware/hypervisor policy). > > > > > > Once firmware sets the enabled bit, the CPU can be registered and > > > brought online by user-space. Online CPUs, or CPUs that are missing > > > an _STA method must always be registered. > > > > ... > > > > > @@ -526,6 +552,9 @@ static void acpi_processor_post_eject(struct acpi_device *device) > > > acpi_processor_make_not_present(device); > > > return; > > > } > > > + > > > + if (cpu_present(pr->id) && !(sta & ACPI_STA_DEVICE_ENABLED)) > > > + arch_unregister_cpu(pr->id); > > > > This change isn't described in the commit log, but seems to be the cause > > of the build error identified by the kernel build bot that is fixed > > later in this series. I'm wondering whether this should be in a > > different patch, maybe "ACPI: Check _STA present bit before making CPUs > > not present" ? > > Would seem a bit odd to call arch_unregister_cpu() way before the code > is added to call the matching arch_registers_cpu() > > Mind you this eject doesn't just apply to those CPUs that are registered > later I think, but instead to all. So we run into the spec hole that > there is no way to identify initially 'enabled' CPUs that might be disabled > later. > > > > > Or maybe my brain isn't working properly (due to being Covid positive.) > > Any thoughts, Jonathan? > > I'll go with a resounding 'not sure' on where this change belongs. > I blame my non existent start of the year hangover. > Hope you have recovered! Looking again, I think you were right, move it to that earlier patch. J > > Jonathan > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
