Re: [PATCH 2/2] firmware: arm_scmi: power_control: Set SCMI_SYSPOWER_IDLE in pm resume

[Peng Fan]

On Mon, Jun 23, 2025 at 06:27:50PM +0530, Dhruva Gole wrote:
>On Jun 20, 2025 at 11:37:14 +0800, Peng Fan (OSS) wrote:
>> From: Peng Fan <peng.fan@xxxxxxx>
>> 
>> When two consecutive suspend message send to the Linux agent, Linux will
>> suspend and wake up. The exepcted behaviour should be suspend, wake up
>
>I am first trying to gather more context of the issue at hand here,
>Why and who is sending 2 consecutive suspend messages to Linux?

Currently in my test, it is SCMI platform send two suspend messages.
But in real cases, other high priviledge agents could send suspend messages
to linux agent.

One agent may wrongly send two suspend messages by user or the agent is hacked.

>
>Just quoting the cover letter:
>
>> When testing on i.MX95, two consecutive suspend message send to the Linux
>> agent, Linux will suspend(by the 1st suspend message) and wake up(by the
>> 2nd suspend message).
>> 
>> The ARM SCMI spec does not allow for filtering of which messages an agent
>> wants to get on the system power protocol. To i.MX95, as we use mailbox
>> to receive message, and the mailbox supports wake up, so linux will also
>> get a repeated suspend message. This will cause Linux to wake (and should
>> then go back into suspend).
>
>When you say mailbox supports wake up you mean the mailbox IP in your
>SoC actually gets some sort of wake interrupt that triggers a wakeup?

There is no dedicated wake interrupt  for mailbox.

The interrupt is the doorbell for processing notification, and this
interrupt could also wakeup Linux.

>Is this wakeup sent to the SM then to be processed further and trigger a
>linux wakeup?

No. As above, the mailbox received a doorbell notification interrupt.

>
><or> the mailbox directly wakes up linux, ie. triggers a resume flow but
>then you are saying it was an unintentional wakeup so you want to
>suspend linux again?

Right.

This just seems like the wakeup routing is
>incorrect and the system is going through a who resume and then suspend
>cycle without a good reason?
>
>Why and when in this flow is linux ending up with a duplicate suspend message is
>something I still don't follow.

Other agents could send duplicated suspend messages, right?
We could not expect other agents always behave correctly.

>
>Could you point us to any flow diagrams or software sequences that we
>could review?

Not sure what kind diagram or sequences you wanna. It is just one agent
wrongly send duplicate suspend message to Linux agent. And Linux agent
should suspend again.

One more example is
Linux suspended, other agent send reboot linux message, Linux should
wakeup and reboot itself.

Same to suspend
Linux suspended, other agent send suspend Linux message, Linux wakeup
and suspend again.

Regards,
Peng
>
>> and suspend again.
>> 
>> The ARM SCMI spec does not allow for filtering of which messages an agent
>> wants to get on the system power protocol. To i.MX95, as we use mailbox
>> to receive message, and the mailbox supports wake up, so linux will also
>> get a repeated suspend message. This will cause Linux to wake (and should
>> then go back into suspend).
>> 
>> In current driver, the state is set back to SCMI_SYSPOWER_IDLE after
>> pm_suspend finish, however the workqueue could be scheduled after
>> thaw_kernel_threads. So the 2nd suspend will return early with
>> "Transition already in progress...ignore", and leave Linux in wakeup
>> state.
>> 
>> So set SCMI_SYSPOWER_IDLE in device resume phase before workqueue
>> is scheduled to make the 2nd suspend message could suspend Linux again.
>> 
>> Signed-off-by: Peng Fan <peng.fan@xxxxxxx>
>> ---
>>  drivers/firmware/arm_scmi/scmi_power_control.c | 24 +++++++++++++++++++-----
>>  1 file changed, 19 insertions(+), 5 deletions(-)
>> 
>[...]
>
>-- 
>Best regards,
>Dhruva Gole
>Texas Instruments Incorporated