[PATCH v2 0/2] mailbox: ti-msgmgr: Fixes for polled rx and trailing bytes

[PATCH v2 0/2] mailbox: ti-msgmgr: Fixes for polled rx and trailing bytes

[Beleswar Padhi]

This series fixes two issues in ti_msgmgr_send_data(), found while
refactoring the ti-msgmgr mbox client (TI-SCI).

Patch 1 fixes a duplicate message transmission in polled rx mode.
Patch 2 stops reading past the end of the message buffer when the
message length is not a multiple of 4. This is a preparatory patch for
when the mbox client can send data which is not a multiple of 4.

This series is independent and can be applied directly.

v2: Changelog:
1. Use memcpy() to construct the trailing word to handle host endianness
(Sashiko bot)

Link to v1:
https://lore.kernel.org/all/20260929200159.4033010-1-b-padhi@ti.com/#t

Testing Done:
 - Boot tested on all TI K3 SoCs.
 - Boot tested on keystone K2G EVMs.
 - Tested that these patches do not introduce any new warning or error.

Logs:
https://gist.github.com/3V3RYONE/18d0c3ce912ab208b53b5887435ff09a

Thanks,
Beleswar

Beleswar Padhi (2):
  mailbox: ti-msgmgr: Do not report rx poll timeout as a send failure
  mailbox: ti-msgmgr: Read exact number of trailing message bytes

 drivers/mailbox/ti-msgmgr.c | 32 +++++++++++++++++++++++++-------
 1 file changed, 25 insertions(+), 7 deletions(-)

-- 
2.34.1

[PATCH v2 1/2] mailbox: ti-msgmgr: Do not report rx poll timeout as a send failure

[Beleswar Padhi]

In polled rx mode, used from system suspend until resume,
ti_msgmgr_send_data() writes the message to the tx queue and then
waits for the response. If no response arrives in time it returns
the poll error.

The mailbox core treats a ->send_data() error as a send failure.
So, it leaves the message queued without making it the active request,
and mbox_send_message() still returns success. The message is then
submitted again on the next tx_tick() or mbox_send_message(), after the
client has probably timed out and moved on. So, the firmware receives
the same message twice, and later requests are sent late and can have
responses matched to the wrong request.

The message has already been transmitted at this point, so return 0
and only log the missing response. The client detects this case with
its own response timeout anyways.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v2: Changelog:
1. None to this patch.

Link to v1:
https://lore.kernel.org/all/20260929200159.4033010-2-b-padhi@ti.com/

 drivers/mailbox/ti-msgmgr.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
index 8eb8df8d95a4c..425d5f9d9d0e3 100644
--- a/drivers/mailbox/ti-msgmgr.c
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -445,12 +445,24 @@ static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data)
 		data_reg += sizeof(u32);
 	}
 
-	/* If we are in polled mode, wait for a response before proceeding */
-	if (ti_msgmgr_chan_has_polled_queue_rx(message->chan_rx))
+	/*
+	 * If we are in polled mode, wait for a response before proceeding.
+	 *
+	 * The message has already been transmitted at this point, so do not
+	 * report a missing response as a send failure. Doing so would make
+	 * the mailbox core keep the message queued and submit it again later,
+	 * after the client has possibly given up on it. The client detects the
+	 * missing response by itself timing out.
+	 */
+	if (ti_msgmgr_chan_has_polled_queue_rx(message->chan_rx)) {
 		ret = ti_msgmgr_queue_rx_poll_timeout(message->chan_rx,
 						      message->timeout_rx_ms * 1000);
+		if (ret)
+			dev_err(dev, "Queue %s timed out waiting for response: %d\n",
+				qinst->name, ret);
+	}
 
-	return ret;
+	return 0;
 }
 
 /**
-- 
2.34.1

[PATCH v2 2/2] mailbox: ti-msgmgr: Read exact number of trailing message bytes

[Beleswar Padhi]

ti_msgmgr_send_data() copies the message to the data registers in u32
units. This has been harmless so far because the clients (TI-SCI)
always passed its preallocated message buffer, which is sized to the
maximum message size (60 or 64 bytes, a multiple of 4), so the extra
bytes read were still within the buffer. But, with a later TI-SCI
update, the message size can be varying now and not guaranteed to be a
multiple of 4, which would trigger KASAN out-of-bounds reports.

Therefore, memcpy() only the trailing bytes into a zeroed u32 before
writing it to the register. This is at most 3 bytes, so the overhead
is negligible.

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
v2: Changelog:
1. Use memcpy() to construct the trailing word to handle host
endianness. (Sashiko bot)

Link to v1:
https://lore.kernel.org/all/20260929200159.4033010-3-b-padhi@ti.com/

 drivers/mailbox/ti-msgmgr.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
index 425d5f9d9d0e3..e04b7f721ac8e 100644
--- a/drivers/mailbox/ti-msgmgr.c
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -20,6 +20,7 @@
 #include <linux/platform_device.h>
 #include <linux/property.h>
 #include <linux/soc/ti/ti-msgmgr.h>
+#include <linux/string.h>
 
 #define Q_DATA_OFFSET(proxy, queue, reg)	\
 		     ((0x10000 * (proxy)) + (0x80 * (queue)) + ((reg) * 4))
@@ -425,10 +426,15 @@ static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data)
 
 	trail_bytes = message->len % sizeof(u32);
 	if (trail_bytes) {
-		u32 data_trail = *word_data;
-
-		/* Ensure all unused data is 0 */
-		data_trail &= 0xFFFFFFFF >> (8 * (sizeof(u32) - trail_bytes));
+		/*
+		 * Copy only the trailing bytes instead of reading a full u32,
+		 * as the message buffer may end right after them and a u32
+		 * read would go past the end of it. This also leaves all
+		 * unused data as 0.
+		 */
+		u32 data_trail = 0;
+
+		memcpy(&data_trail, word_data, trail_bytes);
 		writel(data_trail, data_reg);
 		data_reg += sizeof(u32);
 	}
-- 
2.34.1