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

mmc: wmt-sdmmc: Fix an error handling path in wmt_mci_probe()

2022-10-24T07:57:22+00:00

[ Upstream commit cb58188ad90a61784a56a64f5107faaf2ad323e7 ] A dma_free_coherent() call is missing in the error handling path of the probe, as already done in the remove function. Fixes: 3a96dff0f828 ("mmc: SD/MMC Host Controller for Wondermedia WM8505/WM8650") Signed-off-by: Christophe JAILLET Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/53fc6ffa5d1c428fefeae7d313cf4a669c3a1e98.1663873255.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin

mmc: au1xmmc: Fix an error handling path in au1xmmc_probe()

2022-10-24T07:57:21+00:00

[ Upstream commit 5cbedf52608cc3cbc1c2a9a861fb671620427a20 ] If clk_prepare_enable() fails, there is no point in calling clk_disable_unprepare() in the error handling path. Move the out_clk label at the right place. Fixes: b6507596dfd6 ("MIPS: Alchemy: au1xmmc: use clk framework") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/21d99886d07fa7fcbec74992657dabad98c935c4.1661412818.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin

mmc: sdhci-sprd: Fix minimum clock limit

2022-10-24T07:56:43+00:00

commit 6e141772e6465f937458b35ddcfd0a981b6f5280 upstream. The Spreadtrum controller supports 100KHz minimal clock rate, which means that the current value 400KHz is wrong. Unfortunately this has also lead to fail to initialize some cards, which are allowed to require 100KHz to work. So, let's fix the problem by changing the minimal supported clock rate to 100KHz. Signed-off-by: Wenchao Chen Acked-by: Adrian Hunter Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221011104935.10980-1-wenchao.chen666@gmail.com [Ulf: Clarified to commit-message] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-tegra: Use actual clock rate for SW tuning correction

2022-10-24T07:56:43+00:00

commit b78870e7f41534cc719c295d1f8809aca93aeeab upstream. Ensure tegra_host member "curr_clk_rate" holds the actual clock rate instead of requested clock rate for proper use during tuning correction algorithm. Actual clk rate may not be the same as the requested clk frequency depending on the parent clock source set. Tuning correction algorithm depends on certain parameters which are sensitive to current clk rate. If the host clk is selected instead of the actual clock rate, tuning correction algorithm may end up applying invalid correction, which could result in errors Fixes: ea8fc5953e8b ("mmc: tegra: update hw tuning process") Signed-off-by: Aniruddha TVS Rao Signed-off-by: Prathamesh Shete Acked-by: Adrian Hunter Acked-by: Thierry Reding Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221006130622.22900-4-pshete@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: renesas_sdhi: Fix rounding errors

2022-10-24T07:56:42+00:00

commit f0c00454bf78975925eccc9737faaa4d4951edbf upstream. Due to clk rounding errors on RZ/G2L platforms, it selects a clock source with a lower clock rate compared to a higher one. For eg: The rounding error (533333333 Hz / 4 * 4 = 533333332 Hz < 5333333 33 Hz) selects a clk source of 400 MHz instead of 533.333333 MHz. This patch fixes this issue by adding a margin of (1/1024) higher to the clock rate. Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Fixes: bb6d3fa98a41 ("clk: renesas: rcar-gen3: Switch to new SD clock handling") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220928110755.849275-1-biju.das.jz@bp.renesas.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: hsq: Fix data stomping during mmc recovery

2022-10-05T08:40:46+00:00

commit e7afa79a3b35a27a046a2139f8b20bd6b98155c2 upstream. The block device uses multiple queues to access emmc. There will be up to 3 requests in the hsq of the host. The current code will check whether there is a request doing recovery before entering the queue, but it will not check whether there is a request when the lock is issued. The request is in recovery mode. If there is a request in recovery, then a read and write request is initiated at this time, and the conflict between the request and the recovery request will cause the data to be trampled. Signed-off-by: Wenchao Chen Fixes: 511ce378e16f ("mmc: Add MMC host software queue support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220916090506.10662-1-wenchao.chen666@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: moxart: fix 4-bit bus width and remove 8-bit bus width

2022-10-05T08:40:46+00:00

commit 35ca91d1338ae158f6dcc0de5d1e86197924ffda upstream. According to the datasheet [1] at page 377, 4-bit bus width is turned on by bit 2 of the Bus Width Register. Thus the current bitmask is wrong: define BUS_WIDTH_4 BIT(1) BIT(1) does not work but BIT(2) works. This has been verified on real MOXA hardware with FTSDC010 controller revision 1_6_0. The corrected value of BUS_WIDTH_4 mask collides with: define BUS_WIDTH_8 BIT(2). Additionally, 8-bit bus width mode isn't supported according to the datasheet, so let's remove the corresponding code. [1] https://bitbucket.org/Kasreyn/mkrom-uc7112lx/src/master/documents/FIC8120_DS_v1.2.pdf Fixes: 1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver") Signed-off-by: Sergei Antonov Cc: Jonas Jensen Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220907205753.1577434-1-saproj@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-of-dwcmshc: Re-enable support for the BlueField-3 SoC

2022-09-05T08:31:30+00:00

[ Upstream commit a0753ef66c34c1739580219dca664eda648164b7 ] The commit 08f3dff799d4 (mmc: sdhci-of-dwcmshc: add rockchip platform support") introduces the use of_device_get_match_data() to check for some chips. Unfortunately, it also breaks the BlueField-3 FW, which uses ACPI. To fix the problem, let's add the ACPI match data and the corresponding quirks to re-enable the support for the BlueField-3 SoC. Reviewed-by: David Woods Signed-off-by: Liming Sun Acked-by: Adrian Hunter Fixes: 08f3dff799d4 ("mmc: sdhci-of-dwcmshc: add rockchip platform support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220809173742.178440-1-limings@nvidia.com [Ulf: Clarified the commit message a bit] Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin

mmc: sdhci-of-dwcmshc: rename rk3568 to rk35xx

2022-09-05T08:31:30+00:00

[ Upstream commit 86e1a8e1f9b555af342c53ae06284eeeab9a4263 ] Prepare driver for rk3588 support by renaming the internal data structures. Acked-by: Adrian Hunter Signed-off-by: Sebastian Reichel Link: https://lore.kernel.org/r/20220504213251.264819-11-sebastian.reichel@collabora.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin

mmc: sdhci-of-dwcmshc: add reset call back for rockchip Socs

2022-09-05T08:31:30+00:00

[ Upstream commit 70f832206fe72e9998b46363e8e59e89b0b757bc ] The reset function build in the SDHCI will not reset the logic circuit related to the tuning function, which may cause data reading errors. Resetting the complete SDHCI controller through the reset controller fixes the issue. Signed-off-by: Yifeng Zhao [rebase, use optional variant of reset getter] Acked-by: Adrian Hunter Signed-off-by: Sebastian Reichel Link: https://lore.kernel.org/r/20220504213251.264819-10-sebastian.reichel@collabora.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin