linux-kernel - Re: [PATCH 0/2] firmware: arm_scmi: add pm ops for scmi_power

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aFlpJV_hXvX_nGqV@pluto>
Date: Mon, 23 Jun 2025 15:48:05 +0100
From: Cristian Marussi <cristian.marussi@....com>
To: "Peng Fan (OSS)" <peng.fan@....nxp.com>
Cc: Sudeep Holla <sudeep.holla@....com>,
	Cristian Marussi <cristian.marussi@....com>,
	arm-scmi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	Ranjani Vaidyanathan <ranjani.vaidyanathan@....com>,
	Chuck Cannon <chuck.cannon@....com>, Peng Fan <peng.fan@....com>
Subject: Re: [PATCH 0/2] firmware: arm_scmi: add pm ops for scmi_power_control

On Fri, Jun 20, 2025 at 11:37:12AM +0800, Peng Fan (OSS) wrote:
> 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).
> 

Hi,

> 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).
> 
> This patchset is to make the 2nd suspend message could suspend linux
> again.
> 
> So why SCMI fireware couldn't block the 2nd suspend message from being
> sent to Linux agent? Per checking with our SCMI firmware owner:
> The SM(System Manager) does not know exactly when Linux is in suspend.
> There are no handshakes that clearly tell the SM this. The flow should
> be, if in suspend and you send a suspend (or graceful reset/power off)
> it will wake and then do the request action

Shouldn't the suspended-state of the agent be known to the SCNI server
since:

  A. the SCMI/server has somehow requested a suspend itself sending
     previously a SUSPEND SysPower notification (maybe to fulfill a
     Mnagement entity request)

OR

  B. Linux suspended itself by issuing a PSCI_SUSPEND call to EL3 which
     in turn should have notified the SCMI server os such request by
     issuing a SYSTEM_POWER_STATE_SET to the SCMI server

As in 3.4.1

"On application processors, a PSCI implementation. The PSCI implementation
fulfills OSPM calls to SYSTEM_OFF, SYSTEM_SUSPEND, SYSTEM_RESET and
SYSTEM_RESET2 functions. To do so, the PSCI implementation uses the SCMI
protocol to request system power down or reset transitions."


So how can the SCMI server be NOT aware of the current state of the OSPM
and send a second unneeded message ?

Also addressing Chuck reply later in this thread...

...why if the system is suspended, for whatever reason, and receives a
graceful shutdown notification it does NOT wakeup (due to the
notification received) and then shuwdown to fulfill the request just
received ? Is this the bug ? The wakeup-nortificatin is NOT processed
properly by the driver after it has been woke up ? 

Thanks,
Cristian