On 1/8/26 12:40 PM, Tanmay Kathpalia wrote:
This reverts commit aebb523a23818a8ee4199c9532b51e3d4020696f.
The change to use dev_read_u32_default() with a default value of 0
causes regression for host controller drivers that hardcode f_max
before calling mmc_of_parse().
When the "max-frequency" property is not specified in the device tree,
dev_read_u32_default() returns 0, which overwrites the previously
configured f_max value set by the driver. This effectively resets
the maximum frequency to 0, breaking MMC functionality for those
controllers.
Revert to the original dev_read_u32() behavior which only updates
cfg->f_max when the "max-frequency" property is explicitly present
in the device tree, preserving driver-configured values otherwise.
Signed-off-by: Tanmay Kathpalia <[email protected]>
---
drivers/mmc/mmc-uclass.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index bf0bea93853..2f4dc5bd887 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -243,13 +243,8 @@ int mmc_of_parse(struct udevice *dev, struct mmc_config
*cfg)
return -EINVAL;
}
- /*
- * Maximum frequency is obtained from the optional "max-frequency"
property.
- * If not specified in device tree, defaults to 0 and sdhci_setup_cfg()
- * will set the MMC configuration maximum frequency to the host
controller's
- * maximum base clock frequency from capabilities register.
- */
- cfg->f_max = dev_read_u32_default(dev, "max-frequency", 0);
+ /* f_max is obtained from the optional "max-frequency" property */
+ dev_read_u32(dev, "max-frequency", &cfg->f_max);
Why not do this then ?
cfg->f_max = dev_read_u32_default(dev, "max-frequency", cfg->f_max);
