RE: [PATCH v4] cpuidle: Init cpuidle only for present CPUs
From: Jacky Bai
Date: Fri Mar 07 2025 - 05:26:47 EST
> Subject: Re: [PATCH v4] cpuidle: Init cpuidle only for present CPUs
>
> On Fri, Mar 07, 2025 at 10:10:50AM +0000, Jacky Bai wrote:
> > > Subject: Re: [PATCH v4] cpuidle: Init cpuidle only for present CPUs
> > >
> > > On Fri, Mar 07, 2025 at 10:02:14AM +0000, Jacky Bai wrote:
> > > > Hi Sudeep,
> > > >
> > > > > Subject: Re: [PATCH v4] cpuidle: Init cpuidle only for present
> > > > > CPUs
> > > > >
> > > > > On Fri, Mar 07, 2025 at 04:03:03PM +0800, Jacky Bai wrote:
> > > > > > for_each_possible_cpu() is currently used to initialize
> > > > > > cpuidle in below cpuidle drivers:
> > > > > > drivers/cpuidle/cpuidle-arm.c
> > > > > > drivers/cpuidle/cpuidle-big_little.c
> > > > > > drivers/cpuidle/cpuidle-psci.c
> > > > > > drivers/cpuidle/cpuidle-riscv-sbi.c
> > > > > >
> > > > > > However, in cpu_dev_register_generic(), for_each_present_cpu()
> > > > > > is used to register CPU devices which means the CPU devices
> > > > > > are only registered for present CPUs and not all possible CPUs.
> > > > > >
> > > > > > With nosmp or maxcpus=0, only the boot CPU is present, lead to
> > > > > > the
> > > > > > failure:
> > > > > >
> > > > > > | Failed to register cpuidle device for cpu1
> > > > > >
> > > > > > Then rollback to cancel all CPUs' cpuidle registration.
> > > > > >
> > > > > > Change for_each_possible_cpu() to for_each_present_cpu() in
> > > > > > the above cpuidle drivers to ensure it only registers cpuidle
> > > > > > devices for CPUs that are actually present.
> > > > > >
> > > > > > Fixes: b0c69e1214bc ("drivers: base: Use present CPUs in
> > > > > > GENERIC_CPU_DEVICES")
> > > > > > Reviewed-by: Dhruva Gole <d-gole@xxxxxx>
> > > > > > Reviewed-by: Sudeep Holla <sudeep.holla@xxxxxxx>
> > > > > > Tested-by: Yuanjie Yang <quic_yuanjiey@xxxxxxxxxxx>
> > > > > > Signed-off-by: Jacky Bai <ping.bai@xxxxxxx>
> > > > > > ---
> > > > > > - v4 changes:
> > > > > > - add changes for other cpuidle driver that has the similar issue
> > > > > > as cpuidle-pcsi driver.
> > > > > >
> > > > > > - v3 changes:
> > > > > > - improve the changelog as suggested by Sudeep
> > > > > > ---
> > > > > > drivers/cpuidle/cpuidle-arm.c | 8 ++++----
> > > > > > drivers/cpuidle/cpuidle-big_little.c | 2 +-
> > > > > > drivers/cpuidle/cpuidle-psci.c | 4 ++--
> > > > > > drivers/cpuidle/cpuidle-riscv-sbi.c | 4 ++--
> > > > >
> > > > >
> > > > > Why have you spared drivers/cpuidle/cpuidle-qcom-spm.c ? IIUC
> > > > > the issue exists there as well.
> > > > >
> > > >
> > > > For qcom-spm driver, it has below code logic to handle no cpu
> > > > device case, and no rollback to cancel the whole cpuidle
> > > > registration. So I just leave
> > > it as it is.
> > > > Do we need to update it?
> > > >
> > > > for_each_possible_cpu(cpu) {
> > > > ret = spm_cpuidle_register(&pdev->dev, cpu);
> > >
> > > Did you look into this function ?
> >
> > Yes, at the very beginning of this function it will check if the cpu
> > device is available, if not, directly return -ENODEV, something I
> misunderstood?
> >
>
> So why do you think spm_cpuidle_register() does anything different than
> psci_idle_init_cpu(). They do exactly same check and yet you apply the
> change for psci_idle_init_cpu() but not for spm_cpuidle_register().
> What am I missing ?
>
Thank you, I got your point now. let me update it in next version. :)
BR
> --
> Regards,
> Sudeep