Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

mmc: mmc_spi: Respect the cmd->busy_timeout from the mmc core

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 <j.neuschaefer@gmx.net>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20200414161413.3036-19-ulf.hansson@linaro.org

+6 -3
+6 -3
drivers/mmc/host/mmc_spi.c
··· 242 242 static int mmc_spi_response_get(struct mmc_spi_host *host, 243 243 struct mmc_command *cmd, int cs_on) 244 244 { 245 + unsigned long timeout_ms; 245 246 u8 *cp = host->data->status; 246 247 u8 *end = cp + host->t.len; 247 248 int value = 0; ··· 341 340 /* maybe we read all the busy tokens already */ 342 341 while (cp < end && *cp == 0) 343 342 cp++; 344 - if (cp == end) 345 - mmc_spi_wait_unbusy(host, 346 - msecs_to_jiffies(MMC_SPI_R1B_TIMEOUT_MS)); 343 + if (cp == end) { 344 + timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : 345 + MMC_SPI_R1B_TIMEOUT_MS; 346 + mmc_spi_wait_unbusy(host, msecs_to_jiffies(timeout_ms)); 347 + } 347 348 break; 348 349 349 350 /* SPI R2 == R1 + second status byte; SEND_STATUS