linux-kernel - [PATCH 4.8 20/92] mmc: mmc: Use 500ms as the default generic CMD6 timeout

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20161117103225.037832667@linuxfoundation.org>
Date:   Thu, 17 Nov 2016 11:31:53 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, Ulf Hansson <ulf.hansson@...aro.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Linus Walleij <linus.walleij@...aro.org>
Subject: [PATCH 4.8 20/92] mmc: mmc: Use 500ms as the default generic CMD6 timeout

4.8-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Ulf Hansson <ulf.hansson@...aro.org>

commit fe1b5700c70faac6e027982d59667bc6020de5a8 upstream.

In the eMMC 4.51 version of the spec, an EXT_CSD field called
GENERIC_CMD6_TIME[248] was added. This allows cards to specify the maximum
time it may need to move out from its busy state, when a CMD6 command has
been sent.

In cases when the card is compliant to versions < 4.51 of the eMMC spec,
obviously the core needs to use a fall-back value for this timeout, which
currently is set to 10 minutes. This value is completely in the wrong range
and importantly in some cases it causes a card initialization to take more
than 10 minute to complete.

Earlier this scenario was avoided as the mmc core used CMD13 to poll the
card, to find out when it stopped signaling busy. Commit 08573eaf1a70
("mmc: mmc: do not use CMD13 to get status after speed mode switch")
changed this behavior.

Instead of reverting that commit, which would cause other issues, let's
instead start by picking a simple solution for the problem, by using a
500ms default generic CMD6 timeout.

The reason for using exactly 500ms, comes from observations that shows it's
quite common for cards to specify 250ms. 500ms is two times that value so
likely it should be enough for most cards.

Fixes: 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed
mode switch")
Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
Tested-by: Stephen Boyd <sboyd@...eaurora.org>
Tested-by: Linus Walleij <linus.walleij@...aro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

---
 drivers/mmc/core/mmc.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -26,6 +26,8 @@
 #include "mmc_ops.h"
 #include "sd_ops.h"

+#define DEFAULT_CMD6_TIMEOUT_MS	500
+
 static const unsigned int tran_exp[] = {
 	10000,		100000,		1000000,	10000000,
 	0,		0,		0,		0
@@ -571,6 +573,7 @@ static int mmc_decode_ext_csd(struct mmc
 		card->erased_byte = 0x0;

 	/* eMMC v4.5 or later */
+	card->ext_csd.generic_cmd6_time = DEFAULT_CMD6_TIMEOUT_MS;
 	if (card->ext_csd.rev >= 6) {
 		card->ext_csd.feature_support |= MMC_DISCARD_FEATURE;