u-boot.git/drivers, branch v2026.07

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

drivers: sysreset: revert support for args in request

2026-07-03T19:45:58Z

This reverts: - commit e49c84f7bb7b ("doc: usage: cmd: reset: specify when the -edl option is available") - commit 1076feb8a3f9 ("cmd: boot: fix edl being shown when not supported") - commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset") - commit ef06c5d76ff4 ("cmd: boot: Add '-edl' option to reset command documentation") - commit 32825eaddc37 ("sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs") - commit fcb48b89813b ("drivers: sysreset: Add sysreset op that can take arguments") There was a conflict reverting commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset") due to commit 02ef1859b44f ("configs: Resync with savedefconfig"), but the conflict resolution was trivial. The args support for the sysreset uclass contains a logic bug. The first sysreset device implementing the request_arg callback will consume the args, not support the specified arg and thus return -EPROTONOSUPPORT which will stop the iteration over all sysreset devices. This is an issue if one has multiple sysreset devices and each with support for different (valid) args. If a sysreset device implements a -dummy argument and another -foo and a user calls reset -dummy from the U-Boot CLI, it'll depend on which sysreset device will be attempted first. If it is the one implementing -foo, it'll return it doesn't support the argument with -EPROTONOSUPPORT in which case the device implementing -dummy will never be attempted and instead we'll do a cold reset which is very likely not what's expected from the user. Casey suggested[1] we revert this and start from scratch again with a different implementation instead. [1] https://lore.kernel.org/u-boot/77ff0f56-5c3b-42e7-bdd1-bf90296da900@linaro.org/ Acked-by: Casey Connolly Signed-off-by: Quentin Schulz

clk/qcom: milos: Add TCSRCC clocks

2026-06-30T11:04:59Z

With a recent change to the UFS driver, now all clocks need to be available. Add all the clocks from the TCSRCC block on Milos. Signed-off-by: Luca Weiss Reviewed-by: Casey Connolly Link: https://patch.msgid.link/20260625-milos-ufs-fix-v1-2-b0923dabc35f@fairphone.com Signed-off-by: Casey Connolly

clk/qcom: milos: Add remaining UFS clocks

2026-06-30T11:04:59Z

With a recent change to the UFS driver, now all clocks need to be available. Add them. Signed-off-by: Luca Weiss Reviewed-by: Casey Connolly Link: https://patch.msgid.link/20260625-milos-ufs-fix-v1-1-b0923dabc35f@fairphone.com Signed-off-by: Casey Connolly

clk: imx: imx8mq: Fix iMX8MQ PLL issue

2026-06-27T17:53:01Z

The fractional PLL used on iMX8MQ is not pll14xx, it is different PLL and not exist in u-boot. Add this fractional PLL driver and update iMX8MQ clock driver to adapt this fraction PLL. Fixes: 11c8ab01f3ed ("clk: imx8mq: Add a clock driver for the imx8mq") Signed-off-by: Ye Li Reviewed-by: Peng Fan

net: mtk_eth: select LMB_LIMIT_DMA_BELOW_RAM_TOP

2026-06-24T15:06:16Z

Default to CONFIG_LMB_LIMIT_DMA_BELOW_RAM_TOP=y when MEDIATEK_ETH is enabled. The MediaTek Ethernet controller can only access the first 4GB of RAM when DMA is used. Link: https://patch.msgid.link/20260615-mtk-fix-ram-size-v2-2-f72cfc52ce58@baylibre.com Signed-off-by: David Lechner

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

net: airoha_eth: fix mt7531 mdio related initialization bug

2026-06-23T11:13:16Z

Private data isn't ready during bind time. The call of dev_get_priv() function will return NULL. Thus we can't save mdio device pointer and use it later during probe. To solve an issue, we will move mt7531 mdio device binding to the probing function of 'airoha-eth' driver. All GDM ports (except of GDM1) are connected directly to their PHYs, so corresponding mdio bus will be automatically probed during PHY setup. GDM1 ports differ from other GDM ports. It connected to the airoha switch device. The mt7531 mdio bus is used to manage link state of airoha switch device ports (LAN ports 1-4 corresponds to PHYs 0x09-0x0C). Therefore, manual probing of mt7531 mdio bus is required to be able set/query states of corresponding LAN ports. Fixes: 96d9e7c46425 ("net: airoha: use mt7531 mdio for GDM1") Signed-off-by: Mikhail Kshevetskiy

serial: sh: Fix dev_read_addr error check

2026-06-22T04:34:09Z

dev_read_addr returns FDT_ADDR_T_NONE (-1) in case of error and not 0. Signed-off-by: Francois Berder Reviewed-by: Simon Glass Reviewed-by: Marek Vasut Tested-by: Marek Vasut # R-Car H3/M3-W/M3-N Salvator-X(S), H3/M3-W ULCB, V4H Sparrow Hawk, X5H Ironhide RSIP and CA720AE Signed-off-by: Marek Vasut # Update subject tags