From: Sasha Levin Date: Thu, 26 Aug 2021 12:33:03 +0000 (-0400) Subject: Fixes for 4.4 X-Git-Tag: v5.13.13~1 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=a2c52813df896baa6b27fa54bd3e9be22971c3b4;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.4 Signed-off-by: Sasha Levin --- 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 index 00000000000..f709a5fdd20 --- /dev/null +++ b/queue-4.4/mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch @@ -0,0 +1,66 @@ +From 37069673005cc2581476f49fd1fed6f852e2b601 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 8 Jul 2019 12:56:13 -0700 +Subject: mmc: dw_mmc: Fix occasional hang after tuning on eMMC + +From: Douglas Anderson + +[ 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 +Cc: Marek Szyprowski +Cc: Alim Akhtar +Cc: Enric Balletbo i Serra +Cc: stable@vger.kernel.org +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/series b/queue-4.4/series index 2671e91edd8..8a5af47004d 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -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