kernel/linux.git/drivers/mmc, branch v4.4.235

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: block: return error on failed mmc_blk_get()

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

commit f00ab14c252ac459e86194747a1f580ab503c954 upstream. This used to return -EFAULT, but the function above returns -EINVAL on the same condition so let's stick to that. The removal of error return on this path was introduced with b093410c9aef ('mmc: block: copy resp[] data on err for MMC_IOC_MULTI_CMD'). Fixes: b093410c9aef ('mmc: block: copy resp[] data on err for MMC_IOC_MULTI_CMD'). Signed-off-by: Olof Johansson Cc: Grant Grundler Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: debugfs: correct wrong voltage value

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

commit 0036e74686344f1051afc3107740140abfd03616 upstream. Correct the wrong voltage value shown in debugfs for mmc/sd/sdio. Signed-off-by: Chuanxiao Dong Signed-off-by: Pawel Wodkowski Fixes: 42cd95a0603e ("mmc: core: debugfs: Add signal_voltage to ios dump") Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sd: limit SD card power limit according to cards capabilities

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

commit d9812780a020bcec44565b5950b2a8b31afb5545 upstream. The SD card specification allows cards to error out a SWITCH command where the requested function in a group is not supported. The spec provides for a set of capabilities which indicate which functions are supported. In the case of the power limit, requesting an unsupported power level via the SWITCH command fails, resulting in the power level remaining at the power-on default of 0.72W, even though the host and card may support higher powers levels. This has been seen with SanDisk 8GB cards, which support the default 0.72W and 1.44W (200mA and 400mA) in combination with an iMX6 host, supporting up to 2.88W (800mA). This currently causes us to try to set a power limit function value of '3' (2.88W) which the card errors out on, and thereby causes the power level to remain at 0.72W rather than the desired 1.44W. Arrange to limit the selected current limit by the capabilities reported by the card to avoid the SWITCH command failing. Select the highest current limit that the host and card combination support. Signed-off-by: Russell King Fixes: a39ca6ae0a08 ("mmc: core: Simplify and fix for SD switch processing") 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

mmc: sdhci: fix minimum clock rate for v3 controller

2020-01-29T09:21:51+00:00

commit 2a187d03352086e300daa2044051db00044cd171 upstream. For SDHCIv3+ with programmable clock mode, minimal clock frequency is still base clock / max(divider). Minimal programmable clock frequency is always greater than minimal divided clock frequency. Without this patch, SDHCI uses out-of-spec initial frequency when multiplier is big enough: mmc1: mmc_rescan_try_freq: trying to init card at 468750 Hz [for 480 MHz source clock divided by 1024] The code in sdhci_calc_clk() already chooses a correct SDCLK clock mode. Fixes: c3ed3877625f ("mmc: sdhci: add support for programmable clock mode") Cc: # 4f6aa3264af4: mmc: tegra: Only advertise UHS modes if IO regulator is present Cc: Signed-off-by: Michał Mirosław Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/ffb489519a446caffe7a0a05c4b9372bd52397bb.1579082031.git.mirq-linux@rere.qmqm.pl Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: Update the tuning failed messages to pr_debug level

2020-01-04T12:34:38+00:00

[ Upstream commit 2c92dd20304f505b6ef43d206fff21bda8f1f0ae ] Tuning support in DDR50 speed mode was added in SD Specifications Part1 Physical Layer Specification v3.01. Its not possible to distinguish between v3.00 and v3.01 from the SCR and that is why since commit 4324f6de6d2e ("mmc: core: enable CMD19 tuning for DDR50 mode") tuning failures are ignored in DDR50 speed mode. Cards compatible with v3.00 don't respond to CMD19 in DDR50 and this error gets printed during enumeration and also if retune is triggered at any time during operation. Update the printk level to pr_debug so that these errors don't lead to false error reports. Signed-off-by: Faiz Abbas Cc: stable@vger.kernel.org # v4.4+ Link: https://lore.kernel.org/r/20191206114326.15856-1-faiz_abbas@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman