kernel/linux.git/drivers/mmc, branch v5.10.259

mmc: sdhci: add signal voltage switch in sdhci_resume_host

2026-06-19T11:21:39+00:00

commit f595e8e77a51eee35e331f69321766593a845ef2 upstream. I met one suspend/resume issue with sdr104 capable sdio wifi card (with "keep-power-in-suspend" set in DT property): After resuming from suspend to ram, the sdio wifi card stops working. Further debug shows that although ios shows the sdio card is at sdr104 mode, the voltage is still at 3V3. This is due to missing the calling of ->start_signal_voltage_switch() in sdhci_resume_host(). Fix this issue by adding ->start_signal_voltage_switch() in sdhci_resume_host(). This also matches what we do for sdhci_runtime_resume_host(). Then the question is: why this issue hasn't reported and fixed for so long time. IMHO, several reasons: Some host controllers just kick off the runtime resume for system resume, so they benefit from the well supported runtime pm code; Some platforms just use the old sdio wifi card which doesn't need signal voltage switch at all, the default voltage is 3v3 after resuming. Fixes: 6308d2905bd3 ("mmc: sdhci: add quirk for keeping card power during suspend") Signed-off-by: Jisheng Zhang Acked-by: Adrian Hunter Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: Fix host controller programming for fixed driver type

2026-06-19T11:21:39+00:00

commit 5a52c5701a67d5176eb1afbf1bdaf7d6dfeec597 upstream. When using the fixed-emmc-driver-type device tree property, the MMC core correctly selects the driver strength for the card but fails to program the host controller accordingly. This causes a mismatch where the card uses the specified driver type while the host controller defaults to Type B (since ios->drv_type remains zero). Split the driver type programming logic to handle both fixed and dynamic driver type selection paths. For fixed driver types, program the host controller with the selected drive_strength value. For dynamic selection, use the existing drv_type as before. This ensures both the eMMC device and host controller use matching driver strengths, preventing potential signal integrity issues. Fixes: 6186d06c519e ("mmc: parse new binding for eMMC fixed driver type") Signed-off-by: Kamal Dasu Reviewed-by: Shawn Lin Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: block: use single block write in retry

2026-06-01T15:29:19+00:00

commit c7c6d4f5103864f73ee3a78bfd6da241f84197dd upstream. Due to errata i2493[0], multi-block write would still fail in retries. With i2493, the MMC interface has the potential of write failures when issuing multi-block writes operating in HS200 mode with excessive IO supply noise. While the errata provides guidance in hardware design and layout to minimize the IO supply noise, in theory the write failure cannot be resolved in hardware. The software solution to ensure the data integrity is to add minimum 5us delay between block writes. Single-block write is the practical way to introduce the delay. This patch reuses recovery_mode flag, and switches to single-block write in retry when multi-block write fails. It covers both CQE and non-CQE cases. [0] https://www.ti.com/lit/pdf/sprz582 Cc: stable@vger.kernel.org Suggested-by: Jens Axboe Signed-off-by: Bin Liu Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: vub300: fix NULL-deref on disconnect

2026-04-18T08:31:15+00:00

commit dff34ef879c5e73298443956a8b391311ba78d57 upstream. Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free. Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver") Cc: stable@vger.kernel.org # 3.0+ Signed-off-by: Johan Hovold Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: fix timing selection for 1-bit bus width

2026-04-18T08:30:58+00:00

commit 5e3486e64094c28a526543f1e8aa0d5964b7f02d upstream. When 1-bit bus width is used with HS200/HS400 capabilities set, mmc_select_hs200() returns 0 without actually switching. This causes mmc_select_timing() to skip mmc_select_hs(), leaving eMMC in legacy mode (26MHz) instead of High Speed SDR (52MHz). Per JEDEC eMMC spec section 5.3.2, 1-bit mode supports High Speed SDR. Drop incompatible HS200/HS400/UHS/DDR caps early so timing selection falls through to mmc_select_hs() correctly. Fixes: f2119df6b764 ("mmc: sd: add support for signal voltage switch procedure") Signed-off-by: Luke Wang Acked-by: Adrian Hunter Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-pci-gli: fix GL9750 DMA write corruption

2026-04-18T08:30:58+00:00

commit 2b76e0cc7803e5ab561c875edaba7f6bbd87fbb0 upstream. The GL9750 SD host controller has intermittent data corruption during DMA write operations. The GM_BURST register's R_OSRC_Lmt field (bits 17:16), which limits outstanding DMA read requests from system memory, is not being cleared during initialization. The Windows driver sets R_OSRC_Lmt to zero, limiting requests to the smallest unit. Clear R_OSRC_Lmt to match the Windows driver behavior. This eliminates write corruption verified with f3write/f3read tests while maintaining DMA performance. Cc: stable@vger.kernel.org Fixes: e51df6ce668a ("mmc: host: sdhci-pci: Add Genesys Logic GL975x support") Closes: https://lore.kernel.org/linux-mmc/33d12807-5c72-41ce-8679-57aa11831fad@linux.dev/ Acked-by: Adrian Hunter Signed-off-by: Matthew Schwartz Reviewed-by: Ben Chuang Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: mmci: Fix device_node reference leak in of_get_dml_pipe_index()

2026-04-18T08:30:55+00:00

commit af12e64ae0661546e8b4f5d30d55c5f53a11efe7 upstream. When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In of_get_dml_pipe_index(), it does not release the reference. Fixes: 9cb15142d0e3 ("mmc: mmci: Add qcom dml support to the driver.") Signed-off-by: Felix Gu Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

Revert "mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms"

2026-03-04T12:19:44+00:00

[ Upstream commit ff112f1ecd10b72004eac05bae395e1c65f0c63c ] This reverts commit aced969e9bf3701dc75cfca57c78c031b7875b9d. It was determined that this was not the correct "fix", so should be reverted. Fixes: aced969e9bf3 ("mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms") Cc: Matthew Schwartz Cc: Ulf Hansson Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms

2026-03-04T12:19:44+00:00

[ Upstream commit aced969e9bf3701dc75cfca57c78c031b7875b9d ] The existing 1ms delay in sd_power_on is insufficient and causes resume errors around 4% of the time. Increasing the delay to 5ms resolves this issue after testing 300 s2idle cycles. Fixes: 1f311c94aabd ("mmc: rtsx: add 74 Clocks in power on flow") Signed-off-by: Matthew Schwartz Link: https://patch.msgid.link/20260105060236.400366-3-matthew.schwartz@linux.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

mmc: core: Initial support for SD express card/host

2026-03-04T12:19:43+00:00

[ Upstream commit ead49373d2916080509f51fc6a4ee8f9bc021b9b ] In the SD specification v7.10 the SD express card has been added. This new type of removable SD card, can be managed via a PCIe/NVMe based interface, while also allowing backwards compatibility towards the legacy SD interface. To keep the backwards compatibility, it's required to start the initialization through the legacy SD interface. If it turns out that the mmc host and the SD card, both supports the PCIe/NVMe interface, then a switch should be allowed. Therefore, let's introduce some basic support for this type of SD cards to the mmc core. The mmc host, should set MMC_CAP2_SD_EXP if it supports this interface and MMC_CAP2_SD_EXP_1_2V, if also 1.2V is supported, as to inform the core about it. To deal with the switch to the PCIe/NVMe interface, the mmc host is required to implement a new host ops, ->init_sd_express(). Based on the initial communication between the host and the card, host->ios.timing is set to either MMC_TIMING_SD_EXP or MMC_TIMING_SD_EXP_1_2V, depending on if 1.2V is supported or not. In this way, the mmc host can check these values in its ->init_sd_express() ops, to know how to proceed with the handover. Note that, to manage card insert/removal, the mmc core sticks with using the ->get_cd() callback, which means it's the host's responsibility to make sure it provides valid data, even if the card may be managed by PCIe/NVMe at the moment. As long as the card seems to be present, the mmc core keeps the card powered on. Cc: Greg Kroah-Hartman Cc: Arnd Bergmann Cc: Christoph Hellwig Cc: Rui Feng Signed-off-by: Ulf Hansson Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/1603936636-3126-1-git-send-email-rui_feng@realsil.com.cn Stable-dep-of: aced969e9bf3 ("mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms") Signed-off-by: Sasha Levin