u-boot.git/drivers/mmc, branch next

mmc: socfpga_dw_mmc: Exclude S10 from legacy clkmgr address retrieval

2026-08-19T15:07:05Z

Excluding Stratix10 from legacy implementation of retrieving clkmgr base address as Stratix10's clock driver is already following clock driver model and is supporting enable/disable APIs. The legacy devices' clock driver will continue to be refactored to support driver model which enables us to support enable/disable APIs for all these devices. Signed-off-by: Alif Zakuan Yuslaimi

Merge patch series "Add eMMC support for Axiado SCM3005 board"

2026-08-11T20:55:40Z

Siu Ming Tong says: This series adds eMMC support for the Axiado SCM3005 board, based on the AX3005 SoC, which uses an Arasan SDHCI controller paired with a dedicated eMMC PHY. The series is split as follows: - Patch 1 adds the eMMC PHY driver (PHY_AXIADO_EMMC). The PHY provides signal conditioning and DLL functionality required for high-speed operation with data rates beyond 52MHz, and is based on the Arasan PHY. - Patch 2 adds the SDHCI host controller driver (MMC_SDHCI_AXIADO) for the Arasan controller. It builds on the generic SDHCI framework and adds SoC-specific signal voltage switching, HS200 tuning and eMMC PHY power sequencing through the generic PHY API. - Patch 3 adds the device tree nodes for the SDHCI controller, the eMMC PHY and their supporting fixed clock (clk_xin) to ax3005.dtsi, and enables the SDHCI node in ax3005-scm3005.dts. - Patch 4 enables the new drivers in ax3005_scm3005_defconfig, stores the environment in MMC and bumps CONFIG_SYS_MALLOC_LEN to 0x400000 to accommodate MMC operations. Tested on the Axiado SCM3005 board: the eMMC is detected and enumerated, and read/write access through the MMC subsystem works, including high-speed modes exercised by the PHY tuning path. Link: https://lore.kernel.org/r/20260731-dev-scm3005-v1-0-30bea90ac5f7@axiado.com

mmc: Add Axiado SDHCI driver

2026-08-11T20:55:39Z

Add an SDHCI host controller driver (MMC_SDHCI_AXIADO) for the Arasan SDHCI controller found on the Axiado AX3005 SoC. The driver builds on the generic SDHCI framework and adds SoC-specific handling for signal voltage switching, HS200 tuning and eMMC PHY power sequencing through the generic PHY API. Signed-off-by: Siu Ming Tong

mmc: enable CMD23 for multi-block transfers

2026-07-29T03:15:56Z

Enable the support for the CMD23 (SET_BLOCK_COUNT) command to manage multi-block read/write operations. This allows the MMC core to use CMD23 in preference to the legacy CMD18/CMD25 plus CMD12 sequence, reducing command overhead and improving I/O performance on multi-block transfers. Signed-off-by: Eric Chung Signed-off-by: Tanmay Kathpalia [ Drop MMC_CAP_CMD32 from mvebu_mmc.h ] Signed-off-by: Peng Fan

mmc: fix mmc_deinit regression when card is at 1.8V signaling

2026-07-29T03:15:55Z

Commit 906ee6785b1c ("mmc: sd: Handle UHS-I voltage signaling without power cycle") added detection of cards already operating at 1.8V signaling via mmc_sd_card_using_v18(). This correctly handles the warm-reboot scenario in mmc_startup(). However, mmc_deinit() strips ALL UHS capabilities from the card caps and calls sd_select_mode_and_width() to downgrade the card before kernel handoff. For a card that has switched to 1.8V, uhs_en is already true (via OCR_S18R in mmc->ocr), so sd_select_mode_and_width() attempts UHS mode selection -- but no UHS modes remain in the filtered caps. The non-UHS fallbacks (SD_HS, MMC_LEGACY) are 3.3V speed modes which, when selected while signaling at 1.8V, leave the card in an inconsistent state it cannot recover from without a power cycle. Per SD Physical Layer Specification: "Once the card enters 1.8V signaling mode, the card cannot be switched to 3.3V signaling without power cycle. If the card receives CMD0, card returns to Idle state but still works with SDR12 timing." Fix by using a UHS capability mask that preserves UHS_SDR12 when the card is operating at 1.8V. SDR12 is the minimum valid UHS-I mode and is always available at 1.8V signaling per the SD specification, so the card is left in a consistent (1.8V) state at a low, safe speed. Fixes: 906ee6785b1c ("mmc: sd: Handle UHS-I voltage signaling without power cycle") Reviewed-by: Tanmay Kathpalia Signed-off-by: Peng Fan

mmc: fix mmc_bwrite() ignoring host get_b_max() callback

2026-07-29T03:15:55Z

mmc_bwrite() uses mmc->cfg->b_max directly to limit per-transfer block count. The read path (mmc_bread()) correctly calls mmc_get_b_max() which dispatches to the host driver get_b_max() callback. This callback allows host drivers to enforce DMA boundary constraints based on the buffer address. Fix mmc_bwrite() to use mmc_get_b_max() to match the read path. This requires removing the static qualifier from the non-DM mmc_get_b_max() and adding its declaration to mmc_private.h. Reviewed-by: Tanmay Kathpalia Signed-off-by: Peng Fan

mmc: sdhci: fix align_buffer memory leak on re-initialization

2026-07-29T03:15:55Z

sdhci_init() allocates a 512KB aligned bounce buffer for controllers with SDHCI_QUIRK_32BIT_DMA_ADDR. In the non-DM code path, sdhci_init() is registered as ops->init and called on every mmc_init(). Each call allocates a new buffer without checking or freeing the previous one, leaking 512KB per re-initialization. Fix by guarding the allocation with !host->align_buffer so it only allocates on the first call. Reviewed-by: Tanmay Kathpalia Signed-off-by: Tanmay Kathpalia Signed-off-by: Peng Fan

mmc: rpmb: fix tautological condition in RPMB_REQ_READ_DATA validation

2026-07-29T03:15:55Z

In rpmb_route_frames(), the RPMB_REQ_READ_DATA case checks "req_cnt != 1 || !req_cnt" which is tautological -- !req_cnt (req_cnt == 0) is always a subset of req_cnt != 1. The second operand is dead code. Based on the pattern of all other cases in the switch (RPMB_REQ_KEY, RPMB_REQ_WRITE_DATA, RPMB_REQ_WCOUNTER) which validate rsp_cnt, this was meant to be "req_cnt != 1 || !rsp_cnt". Without this fix, a caller could pass rsp_cnt=0 for a read request without validation. Signed-off-by: Peng Fan

mmc: fix mmc_poll_for_busy() false timeout when card is ready

2026-07-29T03:15:55Z

mmc_poll_for_busy() returns a false -ETIMEDOUT if the card becomes ready on the exact iteration where timeout_ms reaches 0. The card-ready check breaks out of the loop, but then the post-loop check "if (timeout_ms <= 0)" fires and returns -ETIMEDOUT despite the card being ready. Fix by returning 0 directly when the card is ready instead of breaking out of the loop. The only exit from the loop is now the timeout path, so the post-loop code unconditionally returns -ETIMEDOUT. Reviewed-by: Tanmay Kathpalia Signed-off-by: Peng Fan

mmc: sunxi: fix MACH_SUN9I typo in get_mclk_offset()

2026-07-26T20:31:22Z

The get_mclk_offset() function used the non-existent Kconfig symbol CONFIG_MACH_SUN9I_A80 instead of CONFIG_MACH_SUN9I, causing the MMC2 clock register to be written at 0x06000090 instead of 0x06000418. This corrupted the CMD2 response and made eMMC completely unresponsive. Also the legacy (SPL) sunxi_mmc_init() did not include CONFIG_MACH_SUN9I in the 8-bit bus width condition, so MMC2 (eMMC) would only use 4-bit mode in the SPL, which is insufficient for reliable boot. Tested on a Cubieboard4 A80: with both fixes, SPL loads U-Boot proper and boots Debian 12 from eMMC with no SD card present. Signed-off-by: Omar Ivan Fardjoume [Andre: fix mangled patch, trim commit message] Signed-off-by: Andre Przywara