Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-11-26 14:12:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Ulf Hansson 2020-04-14 18:14:12 +02:00
parent 78a67b9224
commit 5671ad667e
1 changed files with 6 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
drivers/mmc/host/mmc_spi.c
View File

@ -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