This is a note to let you know that I've just added the patch titled
mmc: mmci: Add MMC_CAP_NEED_RSP_BUSY for the stm32 variants
to the 5.11-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:
mmc-mmci-add-mmc_cap_need_rsp_busy-for-the-stm32-variants.patch
and it can be found in the queue-5.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From 774514bf977377c9137640a0310bd64eed0f7323 Mon Sep 17 00:00:00 2001
From: Yann Gautier <yann.gautier@xxxxxxxxxxx>
Date: Thu, 25 Feb 2021 15:54:54 +0100
Subject: mmc: mmci: Add MMC_CAP_NEED_RSP_BUSY for the stm32 variants
From: Yann Gautier <yann.gautier@xxxxxxxxxxx>
commit 774514bf977377c9137640a0310bd64eed0f7323 upstream.
An issue has been observed on STM32MP157C-EV1 board, with an erase command
with secure erase argument, ending up waiting for ~4 hours before timeout.
The requested busy timeout from the mmc core ends up with 14784000ms (~4
hours), but the supported host->max_busy_timeout is 86767ms, which leads to
that the core switch to use an R1 response in favor of the R1B and polls
for busy with the host->card_busy() ops. In this case the polling doesn't
work as expected, as we never detects that the card stops signaling busy,
which leads to the following message:
mmc1: Card stuck being busy! __mmc_poll_for_busy
The problem boils done to that the stm32 variants can't use R1 responses in
favor of R1B responses, as it leads to an internal state machine in the
controller to get stuck. To continue to process requests, it would need to
be reset.
To fix this problem, let's set MMC_CAP_NEED_RSP_BUSY for the stm32 variant,
which prevent the mmc core from switching to R1 responses. Additionally,
let's cap the cmd->busy_timeout to the host->max_busy_timeout, thus rely on
86767ms to be sufficient (~66 seconds was need for this test case).
Fixes: 94fe2580a2f3 ("mmc: core: Enable erase/discard/trim support for all mmc hosts")
Signed-off-by: Yann Gautier <yann.gautier@xxxxxxxxxxx>
Link: https://lore.kernel.org/r/20210225145454.12780-1-yann.gautier@xxxxxxxxxxx
Cc: stable@xxxxxxxxxxxxxxx
[Ulf: Simplified the code and extended the commit message]
Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
drivers/mmc/host/mmci.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1241,7 +1241,11 @@ mmci_start_command(struct mmci_host *hos
if (!cmd->busy_timeout)
cmd->busy_timeout = 10 * MSEC_PER_SEC;
- clks = (unsigned long long)cmd->busy_timeout * host->cclk;
+ if (cmd->busy_timeout > host->mmc->max_busy_timeout)
+ clks = (unsigned long long)host->mmc->max_busy_timeout * host->cclk;
+ else
+ clks = (unsigned long long)cmd->busy_timeout * host->cclk;
+
do_div(clks, MSEC_PER_SEC);
writel_relaxed(clks, host->base + MMCIDATATIMER);
}
@@ -2091,6 +2095,10 @@ static int mmci_probe(struct amba_device
mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
}
+ /* Variants with mandatory busy timeout in HW needs R1B responses. */
+ if (variant->busy_timeout)
+ mmc->caps |= MMC_CAP_NEED_RSP_BUSY;
+
/* Prepare a CMD12 - needed to clear the DPSM on some variants. */
host->stop_abort.opcode = MMC_STOP_TRANSMISSION;
host->stop_abort.arg = 0;
Patches currently in stable-queue which might be from yann.gautier@xxxxxxxxxxx are
queue-5.11/mmc-mmci-add-mmc_cap_need_rsp_busy-for-the-stm32-variants.patch
