Re: [PATCH v3 1/4] dt-bindings: arm: psci: Add skip-suspend-mode-switch property
From: Val Packett
Date: Fri Nov 13 2026 - 14:01:06 EST
On 11/13/26 10:09 AM, Ulf Hansson wrote:
+ Sudeep
On Thu, Oct 22, 2026 at 11:41 AM Reza Kurniawan <imkyufie@xxxxxxxxx> wrote:
From: Alejandro Tafalla <atafalla@xxxxxxxxx>I think it would be nice to further clarify what's going on in the
On some SoCs (e.g. Qualcomm MSM8917 and MSM8937), PSCI_FEATURES reports
that OS-initiated mode is supported, but every PSCI_SET_SUSPEND_MODE
call is rejected with NOT_SUPPORTED.
PSCI provides no call to read back the current suspend mode, so the OS
cannot tell which mode the firmware is operating in or why the switch
is rejected.
Add an optional flag that tells the OS not to issue
PSCI_SET_SUSPEND_MODE on such firmware.
PSCI FW. If I understand correctly, the only supported mode is the
PSCI OS-initiated mode, hence it's always running in this mode, right?
This is clearly a violation of the PSCI spec - and I guess updating
the FW isn't possible at this late state, or is it?
[..]
Updating low-level FW in retail devices just doesn't happen, sadly. Can't be done by the user, IIUC not even if Qualcomm wanted to help out, because firmware is signed by the OEM and won't load w/o that signature.
And OEMs, well.. we can't even get the vendors for modern high-end laptops to pull important bug fixes from Qcom.. Thinkpad X13s still requires that stupid arm64.nopauth workaround, retail Hamoa laptops all struggle with the DC ZVA crash/reset (https://github.com/icecream95/x1e-crash) that no one from the Qcom IoT/Linux world has ever encountered because of different firmware apparently, and so on..
MSM8917/MSM8937 are found in decade old low-end mobile e-waste, only could be updated by force if someone finds a bug in firmware secure boot :)
Thanks,
~val