[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<AS8PR04MB86425524495B3FEF19F32E6B87D52@AS8PR04MB8642.eurprd04.prod.outlook.com>
Date: Fri, 7 Mar 2025 10:10:50 +0000
From: Jacky Bai <ping.bai@....com>
To: Sudeep Holla <sudeep.holla@....com>
CC: "rafael@...nel.org" <rafael@...nel.org>, "daniel.lezcano@...aro.org"
<daniel.lezcano@...aro.org>, "lpieralisi@...nel.org" <lpieralisi@...nel.org>,
"ulf.hansson@...aro.org" <ulf.hansson@...aro.org>, "james.morse@....com"
<james.morse@....com>, "d-gole@...com" <d-gole@...com>, "anup@...infault.org"
<anup@...infault.org>, "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
"palmer@...belt.com" <palmer@...belt.com>, "aou@...s.berkeley.edu"
<aou@...s.berkeley.edu>, "linux-pm@...r.kernel.org"
<linux-pm@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-riscv@...ts.infradead.org"
<linux-riscv@...ts.infradead.org>, "imx@...ts.linux.dev"
<imx@...ts.linux.dev>, "khilman@...libre.com" <khilman@...libre.com>,
"quic_tingweiz@...cinc.com" <quic_tingweiz@...cinc.com>,
"quic_yuanjiey@...cinc.com" <quic_yuanjiey@...cinc.com>
Subject: RE: [PATCH v4] cpuidle: Init cpuidle only for present CPUs
> 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@...com>
> > > > Reviewed-by: Sudeep Holla <sudeep.holla@....com>
> > > > Tested-by: Yuanjie Yang <quic_yuanjiey@...cinc.com>
> > > > Signed-off-by: Jacky Bai <ping.bai@....com>
> > > > ---
> > > > - 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?
BR
>
> --
> Regards,
> Sudeep
Powered by blists - more mailing lists