]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 4.4
authorSasha Levin <sashal@kernel.org>
Thu, 26 Aug 2021 12:33:03 +0000 (08:33 -0400)
committerSasha Levin <sashal@kernel.org>
Thu, 26 Aug 2021 12:33:03 +0000 (08:33 -0400)
Signed-off-by: Sasha Levin <sashal@kernel.org>
queue-4.4/mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch [new file with mode: 0644]
queue-4.4/series

diff --git a/queue-4.4/mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch b/queue-4.4/mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch
new file mode 100644 (file)
index 0000000..f709a5f
--- /dev/null
@@ -0,0 +1,66 @@
+From 37069673005cc2581476f49fd1fed6f852e2b601 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 8 Jul 2019 12:56:13 -0700
+Subject: mmc: dw_mmc: Fix occasional hang after tuning on eMMC
+
+From: Douglas Anderson <dianders@chromium.org>
+
+[ Upstream commit ba2d139b02ba684c6c101de42fed782d6cd2b997 ]
+
+In commit 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after
+response errors.") we fixed a tuning-induced hang that I saw when
+stress testing tuning on certain SD cards.  I won't re-hash that whole
+commit, but the summary is that as a normal part of tuning you need to
+deal with transfer errors and there were cases where these transfer
+errors was putting my system into a bad state causing all future
+transfers to fail.  That commit fixed handling of the transfer errors
+for me.
+
+In downstream Chrome OS my fix landed and had the same behavior for
+all SD/MMC commands.  However, it looks like when the commit landed
+upstream we limited it to only SD tuning commands.  Presumably this
+was to try to get around problems that Alim Akhtar reported on exynos
+[1].
+
+Unfortunately while stress testing reboots (and suspend/resume) on
+some rk3288-based Chromebooks I found the same problem on the eMMC on
+some of my Chromebooks (the ones with Hynix eMMC).  Since the eMMC
+tuning command is different (MMC_SEND_TUNING_BLOCK_HS200
+vs. MMC_SEND_TUNING_BLOCK) we were basically getting back into the
+same situation.
+
+I'm hoping that whatever problems exynos was having in the past are
+somehow magically fixed now and we can make the behavior the same for
+all commands.
+
+[1] https://lkml.kernel.org/r/CAGOxZ53WfNbaMe0_AM0qBqU47kAfgmPBVZC8K8Y-_J3mDMqW4A@mail.gmail.com
+
+Fixes: 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after response errors.")
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Cc: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: Alim Akhtar <alim.akhtar@gmail.com>
+Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mmc/host/dw_mmc.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
+index 7bfe9ce03944..9eff3b41a086 100644
+--- a/drivers/mmc/host/dw_mmc.c
++++ b/drivers/mmc/host/dw_mmc.c
+@@ -1762,8 +1762,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
+                                * delayed. Allowing the transfer to take place
+                                * avoids races and keeps things simple.
+                                */
+-                              if ((err != -ETIMEDOUT) &&
+-                                  (cmd->opcode == MMC_SEND_TUNING_BLOCK)) {
++                              if (err != -ETIMEDOUT) {
+                                       state = STATE_SENDING_DATA;
+                                       continue;
+                               }
+-- 
+2.30.2
+
index 2671e91edd86b980ea39da829e6ee404831aa826..8a5af47004d79969a6d5a33c0497b91441b33e0d 100644 (file)
@@ -28,3 +28,4 @@ mmc-dw_mmc-fix-hang-on-data-crc-error.patch
 alsa-hda-fix-the-capture-switch-value-change-notific.patch
 ipack-tpci200-fix-many-double-free-issues-in-tpci200.patch
 asoc-intel-atom-fix-breakage-for-pcm-buffer-address-.patch
+mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch