kernel/git/stable/linux.git/drivers/mmc, branch linux-4.17.y

mmc: pwrseq: Use kmalloc_array instead of stack VLA

2018-08-03T05:47:56+00:00

[ Upstream commit 486e6661367b40f927aadbed73237693396cbf94 ] The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug (kernel Oops) or a security flaw (overwriting memory beyond the stack). Also, in general, as code evolves it is easy to lose track of how big a VLA can get. Thus, we can end up having runtime failures that are hard to debug. As part of the directive[1] to remove all VLAs from the kernel, and build with -Wvla. Currently driver is using a VLA declared using the number of descriptors. This array is used to store integer values and is later used as an argument to `gpiod_set_array_value_cansleep()` This can be avoided by using `kmalloc_array()` to allocate memory for the array of integer values. Memory is free'd before return from function. >From the code it appears that it is safe to sleep so we can use GFP_KERNEL (based _cansleep() suffix of function `gpiod_set_array_value_cansleep()`. It can be expected that this patch will result in a small increase in overhead due to the use of `kmalloc_array()` [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Tobin C. Harding Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mmc: dw_mmc: update actual clock for mmc debugfs

2018-08-03T05:47:56+00:00

[ Upstream commit ff178981bd5fd1667f373098740cb1c6d6efa1ba ] Respect the actual clock for mmc debugfs to help better debug the hardware. mmc_host mmc0: Bus speed (slot 0) = 135475200Hz (slot req 150000000Hz, actual 135475200HZ div = 0) cat /sys/kernel/debug/mmc0/ios clock: 150000000 Hz actual clock: 135475200 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 3 (8 bits) timing spec: 9 (mmc HS200) signal voltage: 0 (1.80 V) driver type: 0 (driver type B) Cc: Xiao Yao Cc: Ziyuan Signed-off-by: Shawn Lin Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-omap: Fix when capabilities are obtained from SDHCI_CAPABILITIES reg

2018-08-03T05:47:56+00:00

[ Upstream commit 0ec4ee3c9b9755b28fd2e89b2ceaae6f15403368 ] sdhci_omap_config_iodelay_pinctrl_state() requires caps and caps2 to be initialized (speed mode capabilities like UHS/HS200) before it is invoked. While mmc_of_parse() initializes caps/caps2 if capabilities is populated in device tree, it will remain uninitialized for capabilities obtained from SDHCI_CAPABILITIES register. Fix sdhci_omap_config_iodelay_pinctrl_state() to be used even while getting the capabilities from SDHCI_CAPABILITIES register by invoking sdhci_setup_host() before sdhci_omap_config_iodelay_pinctrl_state(). Signed-off-by: Kishon Vijay Abraham I Acked-by: Tony Lindgren Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mmc: renesas_sdhi_internal_dmac: Cannot clear the RX_IN_USE in abort

2018-07-17T09:48:23+00:00

commit 25a98edd5795719c5187e16ea271e8de86e02809 upstream. This patch is fixes an issue that the SDHI_INTERNAL_DMAC_RX_IN_USE flag cannot be cleared because tmio_mmc_core sets the host->data to NULL before the tmio_mmc_core calls tmio_mmc_abort_dma(). So, this patch clears the SDHI_INTERNAL_DMAC_RX_IN_USE in the renesas_sdhi_internal_dmac_abort_dma() anyway. This doesn't cause any side effects. Fixes: 0cbc94daa554 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs") Cc: # v4.17+ Signed-off-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: dw_mmc: fix card threshold control configuration

2018-07-17T09:48:23+00:00

commit 7a6b9f4d601dfce8cb68f0dcfd834270280e31e6 upstream. Card write threshold control is supposed to be set since controller version 2.80a for data write in HS400 mode and data read in HS200/HS400/SDR104 mode. However the current code returns without configuring it in the case of data writing in HS400 mode. Meanwhile the patch fixes that the current code goes to 'disable' when doing data reading in HS400 mode. Fixes: 7e4bf1bc9543 ("mmc: dw_mmc: add the card write threshold for HS400 mode") Signed-off-by: Qing Xia Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-esdhc-imx: allow 1.8V modes without 100/200MHz pinctrl states

2018-07-17T09:48:23+00:00

commit 92748beac07c471d995fbec642b63572dc01b3dc upstream. If pinctrl nodes for 100/200MHz are missing, the controller should not select any mode which need signal frequencies 100MHz or higher. To prevent such speed modes the driver currently uses the quirk flag SDHCI_QUIRK2_NO_1_8_V. This works nicely for SD cards since 1.8V signaling is required for all faster modes and slower modes use 3.3V signaling only. However, there are eMMC modes which use 1.8V signaling and run below 100MHz, e.g. DDR52 at 1.8V. With using SDHCI_QUIRK2_NO_1_8_V this mode is prevented. When using a fixed 1.8V regulator as vqmmc-supply the stack has no valid mode to use. In this tenuous situation the kernel continuously prints voltage switching errors: mmc1: Switching to 3.3V signalling voltage failed Avoid using SDHCI_QUIRK2_NO_1_8_V and prevent faster modes by altering the SDHCI capability register. With that the stack is able to select 1.8V modes even if no faster pinctrl states are available: # cat /sys/kernel/debug/mmc1/ios ... timing spec: 8 (mmc DDR52) signal voltage: 1 (1.80 V) ... Link: http://lkml.kernel.org/r/20180628081331.13051-1-stefan@agner.ch Signed-off-by: Stefan Agner Fixes: ad93220de7da ("mmc: sdhci-esdhc-imx: change pinctrl state according to uhs mode") Cc: # v4.13+ Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: renesas_sdhi: really fix WP logic regressions

2018-07-03T09:26:47+00:00

commit ef5332c10d4f332a2ac79e9ad5452f4e89d1815a upstream. This reverts commit e060d376cc61 ("mmc: renesas_sdhi: fix WP detection") and adds some code to really fix the regressions. It was missed so far that Renesas R-Car instantiations of SDHI chose to disable internal WP and used the existence of "wp-gpios" to en/disable WP at all. With the first refactoring by Yamada-san with commit 2ad1db059b9a ("mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag"), WP was always disabled even when GPIOs were present. With Wolfram's first fix which gets now reverted, GPIOs were honored. But when not available, the fallback was to internal WP and not to disabled WP. This caused wrong WP status on uSD card slots. Restore the old behaviour now. By default, WP is disabled. When a GPIO is found, the GPIO re-enables WP. We will think about possible better ways to handle this in the future. Tested on a previously regressing Renesas Lager board (H2) and a still working Renesas Salvator-X board (M3-W). Reported-by: Yoshihiro Shimoda Signed-off-by: Wolfram Sang Cc: stable@vger.kernel.org # v4.17+ Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-iproc: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus

2018-05-21T11:27:22+00:00

The SDHCI_QUIRK2_HOST_OFF_CARD_ON is needed for the driver to properly reset the host controller (reset all) on initialization after exiting deep sleep. Signed-off-by: Corneliu Doban Signed-off-by: Scott Branden Reviewed-by: Ray Jui Reviewed-by: Srinath Mannam Fixes: c833e92bbb60 ("mmc: sdhci-iproc: support standard byte register accesses") Cc: stable@vger.kernel.org # v4.10+ Signed-off-by: Ulf Hansson

mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register

2018-05-21T11:19:48+00:00

When the host controller accepts only 32bit writes, the value of the 16bit TRANSFER_MODE register, that has the same 32bit address as the 16bit COMMAND register, needs to be saved and it will be written in a 32bit write together with the command as this will trigger the host to send the command on the SD interface. When sending the tuning command, TRANSFER_MODE is written and then sdhci_set_transfer_mode reads it back to clear AUTO_CMD12 bit and write it again resulting in wrong value to be written because the initial write value was saved in a shadow and the read-back returned a wrong value, from the register. Fix sdhci_iproc_readw to return the saved value of TRANSFER_MODE when a saved value exist. Same fix for read of BLOCK_SIZE and BLOCK_COUNT registers, that are saved for a different reason, although a scenario that will cause the mentioned problem on this registers is not probable. Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver") Signed-off-by: Corneliu Doban Signed-off-by: Scott Branden Cc: stable@vger.kernel.org # v4.1+ Signed-off-by: Ulf Hansson

mmc: sdhci-iproc: remove hard coded mmc cap 1.8v

2018-05-21T11:15:49+00:00

Remove hard coded mmc cap 1.8v from platform data as it is board specific. The 1.8v DDR mmc caps can be enabled using DTS property for those boards that support it. Fixes: b17b4ab8ce38 ("mmc: sdhci-iproc: define MMC caps in platform data") Signed-off-by: Srinath Mannam Signed-off-by: Scott Branden Reviewed-by: Ray Jui Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: Ulf Hansson