[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DU0PR04MB9417549489A54D23D0F6F57E88082@DU0PR04MB9417.eurprd04.prod.outlook.com>
Date: Tue, 16 Apr 2024 12:26:24 +0000
From: Peng Fan <peng.fan@....com>
To: Sudeep Holla <sudeep.holla@....com>, "Peng Fan (OSS)"
<peng.fan@....nxp.com>
CC: "cristian.marussi@....com" <cristian.marussi@....com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] firmware: arm_scmi: power_control: support suspend
command
Hi Sudeep,
> Subject: Re: [PATCH] firmware: arm_scmi: power_control: support suspend
> command
>
> On Mon, Apr 15, 2024 at 06:11:41PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@....com>
> >
> > Support System suspend notification. Using a work struct to call
> > pm_suspend. There is no way to pass suspend level to pm_suspend, so
> > use MEM as of now.
> >
>
> While the change itself is simple and no-controversial, I am bit worried
> about:
>
> 1. The choice of S2R(MEM) by default - not sure if different system
> prefer different things. The userspace can configure whatever default
> behaviour expected as S2R IIUC, so should be OK. I need to check though.
>
> 2. The userspace needs to keep the wakeup source enabled always which
> I need to check if it is feasible on all the platforms. If wakeups
> are not configured properly and suspend is triggered, the system can
> never resume back.
>
> We may need to mention above points at-least as part of commit log.
ok, I will add the info you listed in V2 commit log.
I would
> wait for some feedback from SCMI users.
Agree.
Thanks,
Peng.
>
> --
> Regards,
> Sudeep
Powered by blists - more mailing lists