Patch "mailbox: imx: fix TXDB_V2 channel race condition" has been added to the 6.10-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

This is a note to let you know that I've just added the patch titled

    mailbox: imx: fix TXDB_V2 channel race condition

to the 6.10-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     mailbox-imx-fix-txdb_v2-channel-race-condition.patch
and it can be found in the queue-6.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 62e952eab03db0934a0ea2c2d6a618c8eee1885e
Author: Peng Fan <peng.fan@xxxxxxx>
Date:   Fri May 24 15:56:32 2024 +0800

    mailbox: imx: fix TXDB_V2 channel race condition
    
    [ Upstream commit b5ef17917f3a797a7b12d1edd51f676554e44a07 ]
    
    Two TXDB_V2 channels are used between Linux and System Manager(SM).
    Channel0 for normal TX, Channel 1 for notification completion.
    The TXDB_V2 trigger logic is using imx_mu_xcr_rmw which uses
    read/modify/update logic.
    
    Note: clear MUB GSR BITs, the MUA side GCR BITs will also got cleared per
    hardware design.
    Channel0 Linux
    read GCR->modify GCR->write GCR->M33 SM->read GSR----->clear GSR
                                                    |-(1)-|
    Channel1 Linux start in time slot(1)
    read GCR->modify GCR->write GCR->M33 SM->read GSR->clear GSR
    So Channel1 read GCR will read back the GCR that Channel0 wrote, because
    M33 has not finish clear GSR, this means Channel1 GCR writing will
    trigger Channel1 and Channel0 interrupt both which is wrong.
    
    Channel0 will be freed(SCMI channel status set to FREE) in M33 SM when
    processing the 1st Channel0 interrupt. So when 2nd interrupt trigger
    (channel 0/1 trigger together), SM will see a freed Channel0, and report
    protocol error.
    
    To address the issue, not using read/modify/update logic, just use
    write, because write 0 to GCR will be ignored. And after write MUA GCR,
    wait the SM to clear MUB GSR by looping MUA GCR value.
    
    Fixes: 5bfe4067d350 ("mailbox: imx: support channel type tx doorbell v2")
    Reviewed-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@xxxxxxx>
    Signed-off-by: Peng Fan <peng.fan@xxxxxxx>
    Signed-off-by: Jassi Brar <jassisinghbrar@xxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 933727f89431d..d17efb1dd0cb1 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -225,6 +225,8 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
 			     void *data)
 {
 	u32 *arg = data;
+	u32 val;
+	int ret;
 
 	switch (cp->type) {
 	case IMX_MU_TYPE_TX:
@@ -236,7 +238,13 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
 		queue_work(system_bh_wq, &cp->txdb_work);
 		break;
 	case IMX_MU_TYPE_TXDB_V2:
-		imx_mu_xcr_rmw(priv, IMX_MU_GCR, IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx), 0);
+		imx_mu_write(priv, IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx),
+			     priv->dcfg->xCR[IMX_MU_GCR]);
+		ret = readl_poll_timeout(priv->base + priv->dcfg->xCR[IMX_MU_GCR], val,
+					 !(val & IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx)),
+					 0, 1000);
+		if (ret)
+			dev_warn_ratelimited(priv->dev, "channel type: %d failure\n", cp->type);
 		break;
 	default:
 		dev_warn_ratelimited(priv->dev, "Send data on wrong channel type: %d\n", cp->type);