[REGRESSION] mmc: "unable to select a mode: -5" on i.MX8M/AM62 platforms

[Francesco Dolcini]

On Thu, Jan 08, 2026 at 01:37:57PM +0530, Tanmay Kathpalia wrote:
> On 1/8/2026 12:32 PM, Max Merchel wrote:
> > Am 08.01.26 um 00:15 schrieb Vitor Soares:
> > > U-Boot 2026.01 fails to initialize MMC devices on multiple platforms
> > > with "unable to select a mode: -5" during mmc_select_mode().
> > > 
> > > Affected platforms:
> > > - Verdin iMX8M Mini (SPL boot failure - cannot boot at all)
> > > - Verdin iMX8M Plus (MMC init fails in U-Boot proper - cannot boot)
> > > - SMARC iMX8M Plus (MMC init fails in U-Boot proper)
> > > - Verdin AM62 (boot failure, no output)
> > > 
> > > All platforms use eMMC and worked correctly prior to this regression.
> > > 
> > > Bisect results:
> > > - Last known good commit: 228810d0bac3
> > > - Known bad commit: 36aeeb591b0d
> > > 
> > > Between these commits, several MMC-related changes were merged. These
> > > seem particularly relevant:
> > > commit aebb523a2381 ("mmc: mmc-uclass: Use max-frequency from device
> > > tree with
> > > default handling")
> > > commit 1e40e419aeb2 ("mmc: sdhci-cadence: Use max-frequency property
> > > from device
> > > tree")
> > > commit fa7e82127fad ("mmc: sdhci-cadence: Set controller and PHY
> > > speed modes for
> > > SD and eMMC cards")

...

> Thanks for the detailed report and bisect results. I've looked into the
> issue, and it appears the regression is introduced by commit aebb523a2381
> ("mmc: mmc-uclass: Use max-frequency from device tree with default
> handling").
> The problem stems from the probe function in the FSL eSDHC driver
> (fsl_esdhc_probe). Here's a breakdown:
> 
> First, fsl_esdhc_init is called, which sets cfg->f_max to the minimum of the
> controller's sdhc_clk and a hardcoded 200 MHz limit:
> cfg->f_max = min(priv->sdhc_clk, (u32)200000000);
> Subsequently, mmc_of_parse is invoked, where in the commit if the
> "max-frequency" property is not specified in the device tree node for the
> MMC controller, this function overrides cfg->f_max to 0.
> 
> This results in f_max being set to 0, which prevents proper mode selection
> during MMC initialization and leads to the "unable to select a mode: -5"
> error you're seeing across those platforms.
> 
> A potential fix could involve either:
> 
> Adding the "max-frequency" property to the relevant device tree nodes (e.g.,
> setting it to 200000000 or the appropriate value based on the hardware).

In general solving a regression in code, adjusting the DT is not ok in
Linux, not sure if the same reasoning would apply in the U-Boot
use case (considering that both U-Boot and DT are firmware).

Francesco