| 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
| ||
|
Message-ID: <06186d01-23e7-4fd6-b5c0-b6c1f8ae7fb7@ti.com>
Date: Fri, 25 Jul 2025 14:29:22 -0500
From: Andrew Davis <afd@...com>
To: Hiago De Franco <hiagofranco@...il.com>,
<linux-remoteproc@...r.kernel.org>
CC: Bjorn Andersson <andersson@...nel.org>,
Mathieu Poirier
<mathieu.poirier@...aro.org>,
Suman Anna <s-anna@...com>, <linux-kernel@...r.kernel.org>,
Hiago De Franco <hiago.franco@...adex.com>
Subject: Re: System can not go into suspend when remoteproc is probed on AM62X
On 7/25/25 10:07 AM, Hiago De Franco wrote:
> Hello everyone,
>
> I noticed something that I am trying to debug, maybe you have any idea
> or tips to help me debugging this issue.
>
> On AM62 and AM62P SoCs that I tested, when the remote proc driver is
> probed, suspend to RAM mode does not work anymore. Without the
> remote proc driver enabled, everything works just fine.
>
> See the driver being probed with AM62 and Cortex M4:
>
> root@...din-am62-15479173:~# dmesg | grep -i -E "remoteproc|rproc|omap-mailbox"
> [ 10.321304] omap-mailbox 29000000.mailbox: omap mailbox rev 0x66fc9100
> [ 10.518369] k3-m4-rproc 5000000.m4fss: assigned reserved memory node m4f-dma-memory@...00000
> [ 10.560055] k3-m4-rproc 5000000.m4fss: configured M4F for remoteproc mode
> [ 10.600283] remoteproc remoteproc0: 5000000.m4fss is available
> [ 10.615269] remoteproc remoteproc0: Direct firmware load for am62-mcu-m4f0_0-fw failed with error -2
> [ 10.650058] remoteproc remoteproc0: powering up 5000000.m4fss
> [ 10.677073] remoteproc remoteproc0: Direct firmware load for am62-mcu-m4f0_0-fw failed with error -2
> [ 10.696173] remoteproc remoteproc0: request_firmware failed: -2
> [ 11.953278] remoteproc remoteproc1: 30074000.pru is available
> [ 11.985475] remoteproc remoteproc2: 30078000.pru is available
>
> And then when trying to to go into suspend:
>
> root@...din-am62-15479173:~# echo mem > /sys/power/state
> [ 41.727649] PM: suspend entry (deep)
> [ 41.738557] Filesystems sync: 0.006 seconds
> [ 41.751535] Freezing user space processes
> [ 41.758692] Freezing user space processes completed (elapsed 0.002 seconds)
> [ 41.765763] OOM killer disabled.
> [ 41.768999] Freezing remaining freezable tasks
> [ 41.774858] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
> [ 41.782333] printk: Suspending console(s) (use no_console_suspend to debug)
> [ 41.830945] omap-mailbox 29000000.mailbox: fifo 1 has unexpected unread messages
> [ 41.830980] omap-mailbox 29000000.mailbox: PM: dpm_run_callback(): platform_pm_suspend returns -16
> [ 41.831013] omap-mailbox 29000000.mailbox: PM: failed to suspend: error -16
> [ 41.831040] PM: Some devices failed to suspend, or early wake event detected
> [ 41.851206] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19
> [ 41.861919] am65-cpsw-nuss 8000000.ethernet end0: PHY [8000f00.mdio:00] driver [TI DP83867] (irq=354)
> [ 41.862921] am65-cpsw-nuss 8000000.ethernet end0: configuring for phy/rgmii-rxid link mode
> [ 41.868493] usb-conn-gpio connector: repeated role: device
> [ 42.012894] OOM killer enabled.
> [ 42.016050] Restarting tasks: Starting
> [ 42.024121] Restarting tasks: Done
> [ 42.033660] random: crng reseeded on system resumption
> [ 42.040482] PM: suspend exit
>
> I believe the issue happens at this line:
>
> [ 41.830945] omap-mailbox 29000000.mailbox: fifo 1 has unexpected unread messages
>
> When the remoteproc driver is probed, the omap-mailbox drivers sends a
> message to Cortex-M4 which is not consumed. Please notice in this case
> there is no firmware running on M4, the driver is only set to "okay"
> into the DTB.
>
> See the debug message with the message being sent ("hfranco"):
>
> root@...din-am62-15479173:~# dmesg | grep -i -E "remoteproc|rproc|omap-mailbox|hfranco"
> [ 10.321304] omap-mailbox 29000000.mailbox: omap mailbox rev 0x66fc9100
> [ 10.518369] k3-m4-rproc 5000000.m4fss: assigned reserved memory node m4f-dma-memory@...00000
> [ 10.560055] k3-m4-rproc 5000000.m4fss: configured M4F for remoteproc mode
> [ 10.577664] hfranco: sending msg 0xffffff03, name mbox-m4-0
> [ 10.600283] remoteproc remoteproc0: 5000000.m4fss is available
> [ 10.615269] remoteproc remoteproc0: Direct firmware load for am62-mcu-m4f0_0-fw failed with error -2
> [ 10.650058] remoteproc remoteproc0: powering up 5000000.m4fss
> [ 10.677073] remoteproc remoteproc0: Direct firmware load for am62-mcu-m4f0_0-fw failed with error -2
> [ 10.696173] remoteproc remoteproc0: request_firmware failed: -2
> [ 11.953278] remoteproc remoteproc1: 30074000.pru is available
> [ 11.985475] remoteproc remoteproc2: 30078000.pru is available
>
> AFAIK, the message in sent when 'send_data' callback is called inside
> mailbox.c, which triggers omap_mbox_chan_send_data() from
> omap-mailbox.c. If I skip this message, suspend to RAM works again, as
> the mailbox will be empty.
>
> Do you know why this message needs to be sent? Is there a way we can
> overcome this issue? Commit 9f0cee984a25 ("mailbox/omap: check for any
> unread messages during suspend") introduced this check.
>
So the issue then looks to be this message we send here when we setup
the mailbox[0]. This mailbox setup is done during probe() for the K3
rproc drivers now (mailbox setup used to be done during
rproc_{start,attach}() before [1]). Moving mailbox setup to probe
is correct, but we should have factored out the test message sending
code out of mailbox setup so it could have been left in
rproc_{start,attach}(). That way we only send this message if the
core is going to be started, no sense in sending that message if
we are not even going to run the core..
Fix might be as simple as [2] (not tested, if this works feel free
to send as a fix)
Andrew
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/ti_k3_common.c#n176
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f3f11cfe890733373ddbb1ce8991ccd4ee5e79e1
[2]
diff --git a/drivers/remoteproc/ti_k3_common.c b/drivers/remoteproc/ti_k3_common.c
index a70d4879a8bea..657a200fa9040 100644
--- a/drivers/remoteproc/ti_k3_common.c
+++ b/drivers/remoteproc/ti_k3_common.c
@@ -198,6 +198,22 @@ int k3_rproc_reset(struct k3_rproc *kproc)
}
EXPORT_SYMBOL_GPL(k3_rproc_reset);
+static int k3_rproc_ping(struct k3_rproc *kproc)
+{
+ /*
+ * Ping the remote processor, this is only for sanity-sake for now;
+ * there is no functional effect whatsoever.
+ *
+ * Note that the reply will _not_ arrive immediately: this message
+ * will wait in the mailbox fifo until the remote processor is booted.
+ */
+ int ret = mbox_send_message(kproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
+ if (ret < 0)
+ dev_err(kproc->dev, "mbox_send_message failed (%pe)\n", ERR_PTR(ret));
+
+ return ret;
+}
+
/* Release the remote processor from reset */
int k3_rproc_release(struct k3_rproc *kproc)
{
@@ -221,6 +237,8 @@ int k3_rproc_release(struct k3_rproc *kproc)
if (ret)
dev_err(dev, "module-reset deassert failed (%pe)\n", ERR_PTR(ret));
+ k3_rproc_ping(kproc);
+
return ret;
}
EXPORT_SYMBOL_GPL(k3_rproc_release);
@@ -243,20 +261,6 @@ int k3_rproc_request_mbox(struct rproc *rproc)
return dev_err_probe(dev, PTR_ERR(kproc->mbox),
"mbox_request_channel failed\n");
- /*
- * Ping the remote processor, this is only for sanity-sake for now;
- * there is no functional effect whatsoever.
- *
- * Note that the reply will _not_ arrive immediately: this message
- * will wait in the mailbox fifo until the remote processor is booted.
- */
- ret = mbox_send_message(kproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
- if (ret < 0) {
- dev_err(dev, "mbox_send_message failed (%pe)\n", ERR_PTR(ret));
- mbox_free_channel(kproc->mbox);
- return ret;
- }
-
return 0;
}
EXPORT_SYMBOL_GPL(k3_rproc_request_mbox);
@@ -397,7 +401,12 @@ EXPORT_SYMBOL_GPL(k3_rproc_stop);
* remote core. This callback is invoked only in IPC-only mode and exists
* because rproc_validate() checks for its existence.
*/
-int k3_rproc_attach(struct rproc *rproc) { return 0; }
+int k3_rproc_attach(struct rproc *rproc)
+{
+ k3_rproc_ping(rproc->priv);
+
+ return 0;
+}
EXPORT_SYMBOL_GPL(k3_rproc_attach);
/*
Powered by blists - more mailing lists