[PATCH] rockchip: rk356x: Stop overriding sdhci/mmc aliases

[Peter Robinson]

> Hi,
>
> On 12/11/2025 11:56 AM, Quentin Schulz wrote:
> > Hi Peter,
> >
> > On 12/9/25 10:18 PM, Peter Robinson wrote:
> >> Upstream device tree has rules where the aliases are board
> >> specific settings, no SoC settings. Looking at upstream
> >> rk356x boards there's a lot of variation in the setting of
> >> mmc0/mmc1 based on the device so we should not be overriding
> >> this here and now we sync to upstream we should just consume
> >> those settings, to do otherwise confuses users.
> >>
> >
> > Do all boards with DM_SEQ_ALIAS config set have these aliases set?
> > Otherwise the MMC device index may change between reboots.
> >
> > While this change is appropriate, we should care to not break users just
> > for the sake of being correct. The easiest check could be to build all
> > rk356* DTB before and after your patch and see if it changes something
> > and for those boards whose DTB changed, whether they use DM_SEQ_ALIAS in
> > some U-Boot phase or not.
>
> To my knowledge all rk33/rk35 boards should be using DM_SEQ_ALIAS in SPL
> and proper in defconfig, at least that is something I have been tested
> or patched in the past for most Rockchip rk33/rk35 SoCs.
>
> The mmc0/mmc1 aliases have been added to the u-boot.dtsi to ensure that
> mmc1  and mmc0 used in e.g. boot_targets env is predictable, similar to
> all older RK SoCs where mmc0=eMMC and mmc1=SD-card (in U-Boot).
>
> Removing these aliases will most likely change boot targets order in
> U-Boot proper, please do not remove these aliases and without first
> having a fix/replacement for the boot targets change in place.

The problem we have is that in cases where Linux is also using the DT
provided by U-Boot we end up with things that can change and we should
not be changing/overriding what the board is specifying, and it's
explicitly forbidden to do this in the upstream DT so we should not be
overriding this.

The reason this came to my attention is because of bug reports of the
way it worked in Linux where they were named differently depending on
whether the U-Boot DT was used in Linux or whether one built from the
Linux kernel tree did.

If there are specific boards that regress with this we should fix the
individual boards rather than use a sledge hammer approach, which is
disallowed for upstream DTs, and which causes other problems for
boards that are doing it correctly.

Peter