linux-stable.git/drivers/mmc/host, branch v4.4.263

mmc: mediatek: fix race condition between msdc_request_timeout and irq

2021-03-17T15:07:20+00:00

[ Upstream commit 0354ca6edd464a2cf332f390581977b8699ed081 ]

when get request SW timeout, if CMD/DAT xfer done irq coming right now,
then there is race between the msdc_request_timeout work and irq handler,
and the host->cmd and host->data may set to NULL in irq handler. also,
current flow ensure that only one path can go to msdc_request_done(), so
no need check the return value of cancel_delayed_work().

Signed-off-by: Chaotian Jing 
Link: https://lore.kernel.org/r/20201218071611.12276-1-chaotian.jing@mediatek.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: mxs-mmc: Fix a resource leak in an error handling path in 'mxs_mmc_probe()'

2021-03-17T15:07:20+00:00

[ Upstream commit 0bb7e560f821c7770973a94e346654c4bdccd42c ]

If 'mmc_of_parse()' fails, we must undo the previous 'dma_request_chan()'
call.

Signed-off-by: Christophe JAILLET 
Link: https://lore.kernel.org/r/20201208203527.49262-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci-esdhc-imx: fix kernel panic when remove module

2021-03-07T10:24:20+00:00

commit a56f44138a2c57047f1ea94ea121af31c595132b upstream.

In sdhci_esdhc_imx_remove() the SDHCI_INT_STATUS in read. Under some
circumstances, this may be done while the device is runtime suspended,
triggering the below splat.

Fix the problem by adding a pm_runtime_get_sync(), before reading the
register, which will turn on clocks etc making the device accessible again.

[ 1811.323148] mmc1: card aaaa removed
[ 1811.347483] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
[ 1811.354988] Modules linked in: sdhci_esdhc_imx(-) sdhci_pltfm sdhci cqhci mmc_block mmc_core [last unloaded: mmc_core]
[ 1811.365726] CPU: 0 PID: 3464 Comm: rmmod Not tainted 5.10.1-sd-99871-g53835a2e8186 #5
[ 1811.373559] Hardware name: Freescale i.MX8DXL EVK (DT)
[ 1811.378705] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
[ 1811.384723] pc : sdhci_esdhc_imx_remove+0x28/0x15c [sdhci_esdhc_imx]
[ 1811.391090] lr : platform_drv_remove+0x2c/0x50
[ 1811.395536] sp : ffff800012c7bcb0
[ 1811.398855] x29: ffff800012c7bcb0 x28: ffff00002c72b900
[ 1811.404181] x27: 0000000000000000 x26: 0000000000000000
[ 1811.409497] x25: 0000000000000000 x24: 0000000000000000
[ 1811.414814] x23: ffff0000042b3890 x22: ffff800009127120
[ 1811.420131] x21: ffff00002c4c9580 x20: ffff0000042d0810
[ 1811.425456] x19: ffff0000042d0800 x18: 0000000000000020
[ 1811.430773] x17: 0000000000000000 x16: 0000000000000000
[ 1811.436089] x15: 0000000000000004 x14: ffff000004019c10
[ 1811.441406] x13: 0000000000000000 x12: 0000000000000020
[ 1811.446723] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
[ 1811.452040] x9 : fefefeff6364626d x8 : 7f7f7f7f7f7f7f7f
[ 1811.457356] x7 : 78725e6473607372 x6 : 0000000080808080
[ 1811.462673] x5 : 0000000000000000 x4 : 0000000000000000
[ 1811.467990] x3 : ffff800011ac1cb0 x2 : 0000000000000000
[ 1811.473307] x1 : ffff8000091214d4 x0 : ffff8000133a0030
[ 1811.478624] Call trace:
[ 1811.481081]  sdhci_esdhc_imx_remove+0x28/0x15c [sdhci_esdhc_imx]
[ 1811.487098]  platform_drv_remove+0x2c/0x50
[ 1811.491198]  __device_release_driver+0x188/0x230
[ 1811.495818]  driver_detach+0xc0/0x14c
[ 1811.499487]  bus_remove_driver+0x5c/0xb0
[ 1811.503413]  driver_unregister+0x30/0x60
[ 1811.507341]  platform_driver_unregister+0x14/0x20
[ 1811.512048]  sdhci_esdhc_imx_driver_exit+0x1c/0x3a8 [sdhci_esdhc_imx]
[ 1811.518495]  __arm64_sys_delete_module+0x19c/0x230
[ 1811.523291]  el0_svc_common.constprop.0+0x78/0x1a0
[ 1811.528086]  do_el0_svc+0x24/0x90
[ 1811.531405]  el0_svc+0x14/0x20
[ 1811.534461]  el0_sync_handler+0x1a4/0x1b0
[ 1811.538474]  el0_sync+0x174/0x180
[ 1811.541801] Code: a9025bf5 f9403e95 f9400ea0 9100c000 (b9400000)
[ 1811.547902] ---[ end trace 3fb1a3bd48ff7be5 ]---

Signed-off-by: Frank Li 
Cc: stable@vger.kernel.org # v4.0+
Link: https://lore.kernel.org/r/20210210181933.29263-1-Frank.Li@nxp.com
[Ulf: Clarified the commit message a bit]
Signed-off-by: Ulf Hansson 
[iwamatsu: adjust context]
Signed-off-by: Nobuhiro Iwamatsu 
Signed-off-by: Greg Kroah-Hartman

mmc: usdhi6rol0: Fix a resource leak in the error handling path of the probe

2021-03-03T15:44:19+00:00

[ Upstream commit 6052b3c370fb82dec28bcfff6d7ec0da84ac087a ]

A call to 'ausdhi6_dma_release()' to undo a previous call to
'usdhi6_dma_request()' is missing in the error handling path of the probe
function.

It is already present in the remove function.

Fixes: 75fa9ea6e3c0 ("mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller")
Signed-off-by: Christophe JAILLET 
Link: https://lore.kernel.org/r/20201217210922.165340-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: via-sdmmc: Fix data race bug

2020-11-10T09:22:13+00:00

[ Upstream commit 87d7ad089b318b4f319bf57f1daa64eb6d1d10ad ]

via_save_pcictrlreg() should be called with host->lock held
as it writes to pm_pcictrl_reg, otherwise there can be a race
condition between via_sd_suspend() and via_sdc_card_detect().
The same pattern is used in the function via_reset_pcictrl()
as well, where via_save_pcictrlreg() is called with host->lock
held.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Madhuparna Bhowmik 
Link: https://lore.kernel.org/r/20200822061528.7035-1-madhuparnabhowmik10@gmail.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

mmc: sdhci: Fix regression setting power on Trats2 board

2020-05-10T08:26:07+00:00

commit 1dceb0415aa0c6bc11dacdab47c9ef83a3604166 upstream.

Several commits relating to setting power have been introducing
problems by putting driver-specific rules into generic SDHCI code.

Krzysztof Kozlowski reported that after commit 918f4cbd4340 ("mmc:
sdhci: restore behavior when setting VDD via external regulator")
on Trats2 board there are warnings for invalid VDD  value (2.8V):

[    3.119656] ------------[ cut here ]------------
[    3.119666] WARNING: CPU: 3 PID: 90 at
../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
[    3.119669] mmc0: Invalid vdd 0x10
[    3.119673] Modules linked in:
[    3.119679] CPU: 3 PID: 90 Comm: kworker/3:1 Tainted: G        W
   4.5.0-next-20160324 #23
[    3.119681] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[    3.119690] Workqueue: events_freezable mmc_rescan
[    3.119708] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[    3.119719] [] (show_stack) from []
(dump_stack+0x88/0x9c)
[    3.119728] [] (dump_stack) from [] (__warn+0xe8/0x100)
[    3.119734] [] (__warn) from []
(warn_slowpath_fmt+0x38/0x48)
[    3.119740] [] (warn_slowpath_fmt) from []
(sdhci_do_set_ios+0x4cc/0x5e0)
[    3.119748] [] (sdhci_do_set_ios) from []
(sdhci_runtime_resume_host+0x60/0x114)
[    3.119758] [] (sdhci_runtime_resume_host) from
[] (__rpm_callback+0x2c/0x60)
[    3.119767] [] (__rpm_callback) from []
(rpm_callback+0x20/0x80)
[    3.119773] [] (rpm_callback) from []
(rpm_resume+0x36c/0x558)
[    3.119780] [] (rpm_resume) from []
(__pm_runtime_resume+0x4c/0x64)
[    3.119788] [] (__pm_runtime_resume) from []
(__mmc_claim_host+0x170/0x1b0)
[    3.119795] [] (__mmc_claim_host) from []
(mmc_rescan+0x54/0x348)
[    3.119807] [] (mmc_rescan) from []
(process_one_work+0x120/0x3f4)
[    3.119815] [] (process_one_work) from []
(worker_thread+0x38/0x554)
[    3.119823] [] (worker_thread) from []
(kthread+0xdc/0xf4)
[    3.119831] [] (kthread) from []
(ret_from_fork+0x14/0x3c)
[    3.119834] ---[ end trace a22d652aa3276886 ]---

Fix by adding a 'set_power' callback and restoring the default
behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore
behavior when setting VDD via external regulator").  The desired
behaviour of that commit is gotten by having sdhci-pxav3 provide
its own set_power callback.

Reported-by: Krzysztof Kozlowski 
Link: http://lkml.kernel.org/r/CAJKOXPcGDnPm-Ykh6wHqV1YxfTaov5E8iVqBoBn4OJc7BnhgEQ@mail.gmail.com
Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
Tested-by: Krzysztof Kozlowski 
Tested-by: Ludovic Desroches 
Signed-off-by: Adrian Hunter 
Cc: stable@vger.kernel.org # v4.5+
Reviewed-by: Jisheng Zhang 
Tested-by: Jisheng Zhang 
Tested-by: Jaehoon Chung 
Tested-by: Anand Moon 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: moxart: fix wait_for_completion_interruptible_timeout return variable type

2020-05-10T08:26:07+00:00

commit 41f469cac2663a41a7b0c84cb94e8f7024385ae4 upstream.

wait_for_completion_timeout_interruptible returns long not unsigned long
so dma_time, which is used exclusively here, is changed to long.

Fixes: 1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver")
Signed-off-by: Nicholas Mc Guire 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: dw_mmc: rockchip: Set the drive phase properly

2020-05-10T08:26:07+00:00

commit d4aa908c7978f60557a799ca53b5ae4166fd8355 upstream.

Historically for Rockchip devices we've relied on the power-on
default (or perhaps the firmware setting) to get the correct drive
phase for dw_mmc devices.  This worked OK for the most part, but:

* Relying on the setting just "being right" is a bit fragile.

* As soon as there is an instance where the power on default is wrong or
  where the firmware didn't configure this properly then we'll get a
  mysterious failure.

In commit 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card
initialization") we actually started setting this explicitly in the
kernel, but that commit wasn't quite right and also wasn't quite
enough.  See  for some
details.

Let's explicitly set this phase in dw_mmc.

The comments inside this patch try to explain the situation quite
throughly, but the high level overview of this is:

Before this patch on rk3288 devices tested (after revert of the clock
patch described above):
* eMMC: 180 degrees
* SDMMC/SDIO0/SDIO1: 90 degrees

After this patch:
* Use 90 degree phase offset usually.
* Use 180 degree phase offset for MMC_DDR52, SDR104, HS200.

That means we are _changing_ behavior for those devices in this way:

* If we have HS200 eMMC or DDR52 eMMC, we'll run ID mode at 90
  degrees (vs 180) but otherwise have no change.

* For any non-HS200 / non-DDR52 eMMC devices we'll now _always_ run at
  90 degrees (vs 180).  It seems fairly unlikely that building modern
  hardware is using an eMMC that isn't using DDR52 or HS200, of course.

* For SDR104 cards we'll now run with 180 degree phase offset (vs 90).
  It's expected that 90 degree phase offset would have worked OK, but
  this gives us extra margin.

I have tested this by inserting my collection of uSD cards (mostly UHS,
though a few not) into a veyron_minnie and confirmed that they still
seem to enumerate properly.  For a subset of them I tried putting a
filesystem on them and also tried running mmc_test.

Fixes: 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization")
Signed-off-by: Douglas Anderson 
Reviewed-by: Shawn Lin 
Tested-by: Heiko Stuebner 
Tested-by: Enric Balletbo i Serra 
Signed-off-by: Jaehoon Chung 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: restore behavior when setting VDD via external regulator

2020-05-10T08:26:06+00:00

commit 918f4cbd4340ddd1eb389cd8efa3b07ac74ec4c0 upstream.

After commit 52221610dd84 ("mmc: sdhci: Improve external VDD regulator
support"), for the VDD is supplied via external regulators, we ignore
the code to convert a VDD voltage request into one of the standard
SDHCI voltage levels, then program it in the SDHCI_POWER_CONTROL. This
brings two issues:

1. SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON quirk isn't handled properly any
more.

2. What's more, once SDHCI_POWER_ON bit is set, some controllers such
as the sdhci-pxav3 used in marvell berlin SoCs require the voltage
levels programming in the SDHCI_POWER_CONTROL register, even the VDD
is supplied by external regulator. So the host in marvell berlin SoCs
still works fine after the commit. However, commit 3cbc6123a93d ("mmc:
sdhci: Set SDHCI_POWER_ON with external vmmc") sets the SDHCI_POWER_ON
bit, this would make the host in marvell berlin SoCs won't work any
more with external vmmc.

This patch restores the behavior when setting VDD through external
regulator by moving the call of mmc_regulator_set_ocr() to the end
of sdhci_set_power() function.

After this patch, the sdcard on Marvell Berlin SoC boards work again.

Signed-off-by: Jisheng Zhang 
Fixes: 52221610dd84 ("mmc: sdhci: Improve external VDD ...")
Reviewed-by: Ludovic Desroches 
Tested-by: Ludovic Desroches 
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

mmc: spi: Toggle SPI polarity, do not hardcode it

2020-02-14T21:29:55+00:00

commit af3ed119329cf9690598c5a562d95dfd128e91d6 upstream.

The code in mmc_spi_initsequence() tries to send a burst with
high chipselect and for this reason hardcodes the device into
SPI_CS_HIGH.

This is not good because the SPI_CS_HIGH flag indicates
logical "asserted" CS not always the physical level. In
some cases the signal is inverted in the GPIO library and
in that case SPI_CS_HIGH is already set, and enforcing
SPI_CS_HIGH again will actually drive it low.

Instead of hard-coding this, toggle the polarity so if the
default is LOW it goes high to assert chipselect but if it
is already high then toggle it low instead.

Cc: Phil Elwell 
Reported-by: Mark Brown 
Signed-off-by: Linus Walleij 
Reviewed-by: Mark Brown 
Link: https://lore.kernel.org/r/20191204152749.12652-1-linus.walleij@linaro.org
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman