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

[Mark Rutland]

On Tue, Jul 21, 2026 at 02:58:49PM +0530, Sneh Mankad wrote:
> 
> 
> On 06-Jul-26 2:46 PM, Sudeep Holla wrote:
> > On Sat, Jul 04, 2026 at 08:43:39AM +0200, Daniel Lezcano wrote:
> >>
> >> Hi Sudeep,
> >>
> >> Le 03/07/2026 à 17:51, Sudeep Holla a écrit :
> >>> (It is always good to cc all PSCI maintainer for any ARM64 CPU
> >>> hotpug/suspend related changes)
> >>>
> >>> On Fri, Jul 03, 2026 at 04:50:02PM +0530, Sneh Mankad wrote:
> >>>> The Qualcomm SoCs like LeMans, Monaco support suspend to ram which leads
> >>>> the SoC to ACPI S3 similar state where SoC is turned off and DDR is
> >>>> retained. The hardware design on these SoCs forces a constraint to suspend
> >>>> and resume the system on boot CPU / CPU0.
> >>>>
> >>> And you fail to explain why they have that constraint.
> > 
> > I still need the above to understand the issue/constraint better.
> 
> Above mentioned SoCs have boot CPU fixed to CPU0 in HW, whenever SoC boots up/cold boots it starts with CPU0.
> 
> These SoCs support suspend to ram which leads to ACPI S3 similar state (where SoC is turned off and DDR is retained)
> PSCI SYSTEM_SUSPEND typically will be executed on boot core itself unless it is already offlined and non boot CPUs gets
> offlined using PSCI CPU_OFF.
> 
> As HW constraint always makes the SoC to boot with boot CPU, consider a scenario, where 
> 
> Boot CPU is already disabled / offline => suspend to ram is triggered => SoC enters ACPI S3 similar state (only DDR is retained and rest of the SoC is off)
> <So far good>
> 
> External wake up arrives (say power key press) => SoC starts booting with CPU0 => CPU0 becomes first one to "land" in kernel now. 

IIUC you're saying that Linux calls SYSTEM_SUSPEND on a CPU other than
CPU0, and the FW returns to Linux on CPU0. The HW constraints are
irrelevant; FW should be handling that transparently from the PoV of
the OS, and even if it always physically boots on CPU0, it should go
wake the other CPU, then offline CPU0.

Look at the PSCI spec:

  https://developer.arm.com/documentation/den0022/fb/

See section 5.20 ("SYSTEM_SUSPEND"), and in particular, the description in
5.20.1 ("Intended use"):

  To use this API, a calling OS must power down all but one core through
  calls to CPU_OFF. From this point on, the remaining core can call
  SYSTEM_SUSPEND, passing the necessary entry_point_address and
  context_id parameters to enable resumption on wakeup. A calling OS can
  use the AFFINITY_INFO function to ensure that all cores are OFF prior
  to calling SYSTEM_SUSPEND.

Note that there's no requirement that the OS calls this on a specific
CPU; just that all others are offline.

Further, note the sentence at the end of that section:

  The core which calls SYSTEM_SUSPEND is the one that resumes execution
  at the specified entry_point_address on wakeup.

... which means that waking up on another CPU is a violation of the
spec.

If we have to deal with broken FW, we can devise something, but this is
*certainly* a firmware bug.

Mark.