Re: [PATCH v2] arm64: Disallow disabling boot CPU based on config

From: Ulf Hansson

Date: Tue Jul 28 2026 - 06:50:46 EST


On Tue, Jul 21, 2026 at 3:53 PM Sudeep Holla <sudeep.holla@xxxxxxxxxx> wrote:
>
> On Tue, Jul 21, 2026 at 02:04:05PM +0100, Mark Rutland wrote:
> > On Tue, Jul 21, 2026 at 12:29:54PM +0530, Sneh Mankad wrote:
> > > On 03-Jul-26 7:58 PM, Mark Rutland wrote:
> > > > On Fri, Jul 03, 2026 at 04:50:02PM +0530, Sneh Mankad wrote:
> > >
> > > FW permits CPU0 disablement because it functions properly in regular run time.
> > > But there is an additional hardware constraint in above mentioned platforms, that
> > > suspend to ram has to be performed via boot CPU / CPU0. Due to this constraint,
> > > CPU0 is required to be online when suspend to ram is triggered.
> >
> > The PSCI spec doesn't permit that.
> >
> > Even if HW has that constraint, it's up to FW to hide that from the OS.
> >
> > [...]
> >
> > > > This is a platform-specific property, and it's possible to build a
> > > > kernel that boots on this platform and/or other platforms.
> > >
> > > Yes, but for that reason the config will only be enabled for SoCs that have this
> > > constraint, it will remain disabled for other SoCs.
> >
> > Please re-read what I said. A config option can't help if you have a
> > single kernel that supports multiple platforms.
> >
>
> +1
>
> > > As mentioned above, its not a FW bug. CPU0 is allowed to be disabled
> > > from FW and HW constraint is for suspend to ram to be performed on
> > > boot CPU.
> >
> > Please see my other reply at:
> >
> > https://lore.kernel.org/linux-arm-kernel/al9tdvOxYb83zBxd@xxxxxxxxxxxxxxxxxxxxxxxxxxxx/T/#m872da3cc4ded3386dce92d4bd4bdf9c33d3e2d0b
> >
> > This is *definitely* a firmware bug.
> >
> > To be clear, I'm not saying we can't do something to address that, but
> > let's not pretend that this is compliant with the PSCI spec.
> >
>
> +1
>
> Just curious if CPU_OFF on this CPU0 returns DENIED or just proceeds and
> ends up with cpu and/or system hang ?

My apologies for side-stepping the discussion, I just wanted to share
that I have explored the exact same problem with other vendor's PSCI
implementations.

In fact, I think it would be interesting to see how many PSCI
implementations that really got this correct. :-)

That said, I think a DT property should be a generic PSCI DT property,
but then set for those platforms that need it.

Kind regards
Uffe