On Wed, 10 Apr 2024 15:28:18 +0200
"Rafael J. Wysocki" <rafael@xxxxxxxxxx> wrote:
> On Wed, Apr 10, 2024 at 2:43 PM Jonathan Cameron
> <Jonathan.Cameron@xxxxxxxxxx> wrote:
> >
> > > >
> > > > > diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> > > > > index 47de0f140ba6..13d052bf13f4 100644
> > > > > --- a/drivers/base/cpu.c
> > > > > +++ b/drivers/base/cpu.c
> > > > > @@ -553,7 +553,11 @@ static void __init cpu_dev_register_generic(void)
> > > > > {
> > > > > int i, ret;
> > > > >
> > > > > - if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES))
> > > > > + /*
> > > > > + * When ACPI is enabled, CPUs are registered via
> > > > > + * acpi_processor_get_info().
> > > > > + */
> > > > > + if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES) || !acpi_disabled)
> > > > > return;
> > > >
> > > > Honestly, this looks like a quick hack to me and it absolutely
> > > > requires an ACK from the x86 maintainers to go anywhere.
> > > Will address this separately.
> > >
> >
> > So do people prefer this hack, or something along lines of the following?
> >
> > static int __init cpu_dev_register_generic(void)
> > {
> > int i, ret = 0;
> >
> > for_each_online_cpu(i) {
> > if (!get_cpu_device(i)) {
> > ret = arch_register_cpu(i);
> > if (ret)
> > pr_warn("register_cpu %d failed (%d)\n", i, ret);
> > }
> > }
> > //Probably just eat the error.
> > return 0;
> > }
> > subsys_initcall_sync(cpu_dev_register_generic);
>
> I would prefer something like the above.
>
> I actually thought that arch_register_cpu() might return something
> like -EPROBE_DEFER when it cannot determine whether or not the CPU is
> really available.
Ok. That would end up looking much more like the original code I think.
So we wouldn't have this late registration at all, or keep it for DT
on arm64? I'm not sure that's a clean solution though leaves
the x86 path alone.
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.
>
> Then, the ACPI processor enumeration path may take care of registering
> CPU that have not been registered so far and in the more-or-less the
> same way regardless of the architecture (modulo some arch-specific
> stuff).
If I understand correctly, in acpi_processor_get_info() we'd end up
with a similar check on whether it was already registered (the x86 path)
or had be deferred (arm64 / acpi).
>
> In the end, it should be possible to avoid changing the behavior of
> x86 and loongarch in this series.
Possible, yes, but result if I understand correctly is we end up with
very different flows and replication of functionality between the
early registration and the late one. I'm fine with that if you prefer it!
>
> > Which may look familiar at it's effectively patch 3 from v3 which was dealing
> > with CPUs missing from DSDT (something we think doesn't happen).
> >
> > It might be possible to elide the arch_register_cpu() in
> > make_present() but that will mean we use different flows in this patch set
> > for the hotplug and initially present cases which is a bit messy.
> >
> > I've tested this lightly on arm64 and x86 ACPI + DT booting and it "seems" fine.
>
> Sounds promising.
Possibly not that relevant though if proposal is to drop this approach. :(
At least I now have test setups!
Jonathan
>
> Thanks!
