From: Thomas Gleixner <tglx@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>,
Sneh Mankad <sneh.mankad@oss.qualcomm.com>
Cc: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Pavel Machek <pavel@kernel.org>, Len Brown <lenb@kernel.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org
Subject: Re: [PATCH] kernel/cpu: Disallow offlining boot CPU based on config
Date: Fri, 05 Jun 2026 14:20:57 +0200 [thread overview]
Message-ID: <87ik7x5gba.ffs@fw13> (raw)
In-Reply-To: <20260605104330.GX3102624@noisy.programming.kicks-ass.net>
On Fri, Jun 05 2026 at 12:43, Peter Zijlstra wrote:
> On Fri, Jun 05, 2026 at 04:00:46PM +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.
>>
>> If CPU0 is already offline before starting suspend to ram the
>> freeze_secondary_cpus() picks alternate CPU as primary / last CPU and
>> proceed further to invoke PSCI SYSTEM_SUSPEND.
>> This leads to a system crash.
>>
>> In order to prevent such an issue introduce PM_SLEEP_SMP_CPU_ZERO_STRICT
>> config and when enabled prohibit the CPU0 to be offline.
>
> Why do this in generic code? Why can't this live in arch code.
> Specifically, x86 can't typically unplug CPU0 at all either.
arch_cpu_is_hotpluggable(cpu) provides that info to the cpu device core.
No hackery in cpu.c required at all.
Thanks,
tglx
next prev parent reply other threads:[~2026-06-05 12:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 10:30 [PATCH] kernel/cpu: Disallow offlining boot CPU based on config Sneh Mankad
2026-06-05 10:43 ` Peter Zijlstra
2026-06-05 12:20 ` Thomas Gleixner [this message]
2026-06-05 13:07 ` Pankaj Patil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ik7x5gba.ffs@fw13 \
--to=tglx@kernel.org \
--cc=daniel.lezcano@oss.qualcomm.com \
--cc=lenb@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=sneh.mankad@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.