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

treewide: Kconfig: use bool instead of tristate

2026-07-10T21:45:57Z

U-Boot does not support modules, so having tristate options is useless. Therefore this patch does a blind replace of all tristate options to bool tree-wide. Signed-off-by: Anshul Dalal Reviewed-by: Heiko Schocher Reviewed-by: Quentin Schulz Reviewed-by: Siddharth Vadapalli Reviewed-by: Neha Malcom Francis Reviewed-by: Romain Gantois Reviewed-by: Simon Glass

Merge branch 'next'

2026-07-07T00:26:12Z

Revert "mmc: sdhci-cadence: trigger tuning for SD HS mode on SD6HC (v6) PHY"

2026-07-06T06:06:27Z

This reverts commit b42c67188c14 ("mmc: sdhci-cadence: trigger tuning for SD HS mode on SD6HC (v6) PHY"). The reverted patch introduced several issues: 1. Non-standard tuning trigger: The SD Physical Layer Specification only mandates execute_tuning for SDR50 and SDR104 UHS-I modes. Triggering tuning for SD High Speed mode is outside the spec and is handled via a non-standard set_ios_post callback rather than through the established SDHCI framework tuning path. 2. Non-standard device tree property: The patch introduced a new "cdns,sd-hs-tuning" DT property to opt into SD HS tuning. This is not aligned with existing DT bindings and bypasses the standard MMC capability negotiation mechanism. 3. Incorrect tunable mode allowlist: The sdhci_cdns6_mode_is_tuned() function includes SD_HS, UHS_SDR50, and MMC_HS_400_ES as tunable modes. According to the Cadence SD6HC IP User Guide (section 7.5.2, Figure 18), tuning is only required for UHS-I SDR104 (SD) and HS200 (eMMC). SD High Speed, UHS-I SDR50, and DDR50 only require a PHY settings update from the pre-calculation script, not the tuning procedure. HS400 transitions through HS200 and reuses its tuned DLL value with a partial settings update. HS400ES only requires a plain settings update from the calculation script with no dependency on HS200 tuning. 4. Tuned state management outside the framework: The patch manually tracks tuned DLL state (tuned_mode, tuned_dll_slave_ctrl) and restores it across PHY reconfigurations. This duplicates responsibility that belongs in the core MMC tuning framework and adds unnecessary complexity to the driver. Reverting to realign the driver with the IP documentation and the SD Physical Layer Specification. Signed-off-by: Tanmay Kathpalia Signed-off-by: Peng Fan

mmc: sd: fix redundant 1.8V voltage switch on cold boot with UHS card

2026-07-06T06:06:08Z

When a UHS card successfully negotiates 1.8V signaling during normal initialization, the host voltage switch is performed as part of the ACMD41 handshake. Without this fix, the warm-reboot recovery path would fire again immediately after, switching the host voltage a second time unnecessarily. Add a check so the recovery path is only entered when the voltage switch was not already performed during the current initialization session. Fixes: 906ee6785b1c ("mmc: sd: Handle UHS-I voltage signaling without power cycle") Signed-off-by: Tanmay Kathpalia Signed-off-by: Peng Fan

treewide: Staticize and constify acpi ops

2026-06-29T21:29:44Z

Set the acpi_ops structure as static const where applicable. The The structure is not accessible from outside of drivers and is not going to be modified at runtime. The structure may be unused in a couple of drivers depending on their configuration, mark those sites with __maybe_unused . Signed-off-by: Marek Vasut Reviewed-by: Simon Glass

Kconfig: drivers: restyle remaining

2026-06-25T21:00:58Z

Restyle all Kconfigs for the rest of "drivers": Menu entries : no space left Menu attributes: 1 TAB Help text : 1 TAB + 2 spaces Replace '---help---' by 'help' Signed-off-by: Johan Jonker [trini: Add missing indentation on a few more multi-paragraph help texts] Signed-off-by: Tom Rini

treewide: move bi_dram[] from bd to gd

2026-06-25T00:13:24Z

Currently, the bi_dram[] information is stored in the board info structure (bd). Because bd is only valid after reserve_board(), dram_init_banksize() must be called late in the initialization process. This limitation is problematic, as it forces us to rely on a variety of bespoke functions to determine board RAM, bank memory sizes, and other early setup requirements. By moving bi_dram[] into the global data (gd), we can run it earlier. This is particularly convenient since boards define their own dram_init_banksize() routines, which do not always rely on parsing Device Tree (DT) memory nodes. Additionally, U-Boot defaults to relocating to the top of the first memory bank. While boards currently use custom functions to override this behavior, having the DRAM bank information available earlier in gd makes relocating to a different bank trivial and standardizes the process. Reviewed-by: Anshul Dalal Tested-by: Michal Simek # Versal Gen 2 Vek385 Tested-by: Anshul Dalal Reviewed-by: Simon Glass Signed-off-by: Ilias Apalodimas Tested-by: Christophe Leroy (CS GROUP)

mmc: mtk-sd: select LMB_LIMIT_DMA_BELOW_RAM_TOP

2026-06-24T15:06:16Z

Default to CONFIG_LMB_LIMIT_DMA_BELOW_RAM_TOP=y when CONFIG_MTK_SD is enabled. The MediaTek SD controller can only access the first 4GB of RAM when DMA is used. "imply" is used rather than "select" in case someone want's to turn off the option when DMA is not used. Link: https://patch.msgid.link/20260615-mtk-fix-ram-size-v2-1-f72cfc52ce58@baylibre.com Signed-off-by: David Lechner

Merge patch series "arm: omap: Add back omap4 support"

2026-06-17T15:52:33Z

Bastien Curutchet says: This series aims to add back the omap4 support. This support was removed by commit b0ee3fe642c ("arm: ti: Remove omap4 platform support") because at that moment, none of the OMAP4-based boards had done the migration to DM_I2C. My use case is an old product based on the Variscite's omap4 system on module. I needed to upgrade U-Boot on it for security reasons. I think that this work could benefit to other people who may have same kind of product to maintain. Patch 1 to 3 remove the omap's clock driver dependency to the AM33xx as it is also present in omap4 platforms. I tested these changes on the beaglebone black to ensure I didn't break the AM33xx case. Patch 4 & 5 revert the deletion of the omap4 support. The revert makes checkpatch.pl angry. I fixed quite a lots of warnings already but it remains two kinds of warnings: - CamelCase on timings structure, I left the CamelCase because IMHO it's more readable this way. - #ifdef CONFIG_XYZ shouldn't be used anymore. I left one of this because I didn't find a clean way to get rid of it. Patch 6 adds support for the Variscite's system on module. This system on module is supported by the Linux project through ti/omap/omap4-var-som-om44.dtsi Link: https://lore.kernel.org/r/20260608-omap4-support-v3-0-8595ccd203f0@bootlin.com

arm: ti: Introduce back omap4 support

2026-06-17T15:50:36Z

omap4 support was dropped by b0ee3fe642c ("arm: ti: Remove omap4 platform support") because the supported boards hadn't done the conversion to CONFIG_DM_I2C in time. It still exists some omap4-based products and they could benefit from the latest U-Boot support for obvious security reasons. Revert part of b0ee3fe642c to introduce back a minimal support for the omap4 platform. Fix the checkpatch's warning/errors induced by this revert. Following warnings are still present: | arch/arm/include/asm/arch-omap4/clock.h:445: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? | arch/arm/mach-omap2/omap4/hwinit.c:24: WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible | arch/arm/mach-omap2/omap4/sdram_elpida.c:142: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:143: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:144: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:145: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:146: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:147: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:148: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:149: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:150: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:151: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:152: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:153: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:154: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:155: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:156: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:157: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:158: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:159: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:209: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:210: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:213: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:215: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:216: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:217: CHECK: Avoid CamelCase: I didn't find an clean way to fix the "don't use #ifdef" warning as we need to define the gpio_bank for the SPL build only. For the CamelCase warnings, the incriminated attributes represent timings, so IMHO, it is more readable with CamelCase. Set myself as OMAP4 maintainer. Signed-off-by: Bastien Curutchet