From 9b4cf9cd09b32544817d0fa653fe18a6ec8ceea2 Mon Sep 17 00:00:00 2001 From: Ulf Hansson Date: Tue, 14 Apr 2020 18:14:12 +0200 Subject: [PATCH] mmc: mmc_spi: Respect the cmd->busy_timeout from the mmc core MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Using a fixed 3s polling timeout for all commands with R1B responses is a bit problematic. For some commands it means waiting longer than needed for the polling to be aborted, which may not a big issue, but still. For other commands, like for an erase (CMD38), may require longer timeouts than 3s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Jonathan Neuschäfer Cc: Linus Walleij Signed-off-by: Ulf Hansson Link: https://lore.kernel.org/r/20200414161413.3036-19-ulf.hansson@linaro.org --- drivers/mmc/host/mmc_spi.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c index 5768fe9f8f6f5..39bb1e30c2d72 100644 --- a/drivers/mmc/host/mmc_spi.c +++ b/drivers/mmc/host/mmc_spi.c @@ -242,6 +242,7 @@ static char *maptype(struct mmc_command *cmd) static int mmc_spi_response_get(struct mmc_spi_host *host, struct mmc_command *cmd, int cs_on) { + unsigned long timeout_ms; u8 *cp = host->data->status; u8 *end = cp + host->t.len; int value = 0; @@ -340,9 +341,11 @@ checkstatus: /* maybe we read all the busy tokens already */ while (cp < end && *cp == 0) cp++; - if (cp == end) - mmc_spi_wait_unbusy(host, - msecs_to_jiffies(MMC_SPI_R1B_TIMEOUT_MS)); + if (cp == end) { + timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : + MMC_SPI_R1B_TIMEOUT_MS; + mmc_spi_wait_unbusy(host, msecs_to_jiffies(timeout_ms)); + } break; /* SPI R2 == R1 + second status byte; SEND_STATUS -- 2.39.5