From: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Jon Hunter <jonathanh@nvidia.com>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>,
mark.rutland@arm.com, bjorn.andersson@oss.qualcomm.com,
konrad.dybcio@oss.qualcomm.com, mani@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Konrad Dybcio <konradybcio@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Sudeep Holla <sudeep.holla@arm.com>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH] firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
Date: Tue, 24 Mar 2026 09:45:16 +0100 [thread overview]
Message-ID: <acJPHGIW1fb7whsu@lpieralisi> (raw)
In-Reply-To: <b5860d64-6eed-453e-8261-2c8b0c5571c4@nvidia.com>
On Mon, Mar 23, 2026 at 10:10:00AM +0000, Jon Hunter wrote:
> Hi Mark, Lorenzo,
>
> On 12/03/2026 19:00, Jon Hunter wrote:
> > Hi all,
> >
> > On 31/12/2025 16:21, Manivannan Sadhasivam wrote:
> > > From: Konrad Dybcio <konradybcio@kernel.org>
> > >
> > > PSCI specification defines the SYSTEM_SUSPEND feature which enables the
> > > firmware to implement the suspend to RAM (S2RAM) functionality by
> > > transitioning the system to a deeper low power state. When the system
> > > enters such state, the power to the peripheral devices might be
> > > removed. So
> > > the respective device drivers must prepare for the possible removal
> > > of the
> > > power by performing actions such as shutting down or resetting the device
> > > in their system suspend callbacks.
> > >
> > > The Linux PM framework allows the platform drivers to convey this info to
> > > device drivers by calling the pm_set_suspend_via_firmware() and
> > > pm_set_resume_via_firmware() APIs.
> > >
> > > Hence, if the PSCI firmware supports SYSTEM_SUSPEND feature, call
> > > the above
> > > mentioned APIs in the psci_system_suspend_begin() and
> > > psci_system_suspend_enter() callbacks.
> > >
> > > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> > > Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> > > [mani: reworded the description to be more elaborative]
> > > Signed-off-by: Manivannan Sadhasivam
> > > <manivannan.sadhasivam@oss.qualcomm.com>
> > > ---
> > >
> > > This patch was part of an old series that didn't make it to mainline
> > > due to
> > > objections in the binding and exposing CPU_SUSPEND as S2RAM patches:
> > > https://lore.kernel.org/all/20241028-topic-cpu_suspend_s2ram-
> > > v1-0-9fdd9a04b75c@oss.qualcomm.com/
> > >
> > > But this patch on its own is useful for platforms implementing the S2RAM
> > > feature in PSCI firmware. So I picked it up, tested on Qcom X1E T14s and
> > > resending it.
> > >
> > > drivers/firmware/psci/psci.c | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> > > index 38ca190d4a22..e73bae6cb23a 100644
> > > --- a/drivers/firmware/psci/psci.c
> > > +++ b/drivers/firmware/psci/psci.c
> > > @@ -539,12 +539,22 @@ static int psci_system_suspend(unsigned long
> > > unused)
> > > static int psci_system_suspend_enter(suspend_state_t state)
> > > {
> > > + pm_set_resume_via_firmware();
> > > +
> > > return cpu_suspend(0, psci_system_suspend);
> > > }
> > > +static int psci_system_suspend_begin(suspend_state_t state)
> > > +{
> > > + pm_set_suspend_via_firmware();
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static const struct platform_suspend_ops psci_suspend_ops = {
> > > .valid = suspend_valid_only_mem,
> > > .enter = psci_system_suspend_enter,
> > > + .begin = psci_system_suspend_begin,
> > > };
> > > static void __init psci_init_system_reset2(void)
> >
> >
> > I wanted to ask what the status of this patch is?
> >
> > It turns out that since commit f3ac2ff14834 ("PCI/ASPM: Enable all
> > ClockPM and ASPM states for devicetree platforms"), this fix is also
> > need for Tegra platforms that have NVMe devices to ensure that they are
> > suspended as needed. There is some more background in this thread [0].
>
>
> Any feedback on this? I am not sure if this patch is purposely being
> ignored, but if so, I would like to understand why.
It fell through the cracks, apologies.
Lorenzo
next prev parent reply other threads:[~2026-03-24 8:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-31 16:21 [PATCH] firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND Manivannan Sadhasivam
2026-03-12 19:00 ` Jon Hunter
2026-03-23 10:10 ` Jon Hunter
2026-03-24 8:45 ` Lorenzo Pieralisi [this message]
2026-03-24 8:44 ` Lorenzo Pieralisi
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=acJPHGIW1fb7whsu@lpieralisi \
--to=lpieralisi@kernel.org \
--cc=bjorn.andersson@oss.qualcomm.com \
--cc=jonathanh@nvidia.com \
--cc=konrad.dybcio@linaro.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mani@kernel.org \
--cc=manivannan.sadhasivam@oss.qualcomm.com \
--cc=mark.rutland@arm.com \
--cc=sudeep.holla@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox