Re: [PATCH] dts: Re-add aliases for imx6qdl-sabrelite devices

Tom Rini
2022-12-05T15:37:14Z

[-- Attachment #1: Type: text/plain, Size: 2709 bytes --]

On Sat, Dec 03, 2022 at 09:23:10AM -0300, Fabio Estevam wrote:
> On Fri, Dec 2, 2022 at 8:36 PM Tom Rini <trini@konsulko.com> wrote:
>
> > No, upstream has different aliases and doesn't want these. That's the
> > point of the above thread, right?
>
> Upstream is correct in not accepting new alias for this board, as this
> could break
> existing setups.
>
> In U-Boot, we had alias for this board originally. After the sync with
> Linux they are gone.
>
> To fix U-Boot, the less invasive change is to add the alias into
> arch/arm/dts/imx6qdl-sabrelite-u-boot.dtsi.
>
> This way we can:
>
> 1. Keep the dtsi in sync with Linux
>
> 2. Do not break users in U-Boot
>
> This is the same approach I did for wandboard in the following commit:
>
> commit f827f84d3f5607d0b33e927f6127a888e7bd664f
> Author: Fabio Estevam <festevam@denx.de>
> Date: Fri Nov 4 08:12:54 2022 -0300
>
> wandboard: Pass mmc aliases
>
> Originally, the mmc aliases node was present in imx6qdl-wandboard.dtsi.
>
> After the sync with Linux in commit d0399a46e7cd ("imx6dl/imx6qdl:
> synchronise device trees with linux"), the aliases node is gone as
> the upstream version does not have it.
>
> This causes a regression in which the SD card cannot be found anymore:
>
> Since commit the aliases node has been removed
> U-Boot 2022.10-00999-gcca41ed3d63f-dirty (Nov 03 2022 - 22:07:38 -0300)
>
> CPU: Freescale i.MX6QP rev1.0 at 792 MHz
> Reset cause: POR
> DRAM: 2 GiB
> Core: 62 devices, 17 uclasses, devicetree: separate
> PMIC: PFUZE100 ID=0x10
> MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... MMC: no card present
> *** Warning - No block device, using default environment
>
> Fix it by passing the alias node in the u-boot.dtsi file to
> restore the original behaviour where the SD card (esdhc3) was
> mapped to mmc0.
>
> Fixes: d0399a46e7cd ("imx6dl/imx6qdl: synchronise device trees with linux")
> Signed-off-by: Fabio Estevam <festevam@denx.de>

I'm not really happy with this approach. It's not that upstream doesn't
have aliases now, it's that it has different aliases, right? That's why
they won't accept these?

But this also highlights that we really need to get these kind of
aliases and similar (a) re-synced with upstream ASAP and (b) do that at
the start. I don't know which group of "users are broken by this change"
is bigger, the group that needs the aliases we have or the group that
needs the other aliases, but the group that gets changes upstream first
"wins" here is how the OSS world works.

--
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]