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:
Keep the dtsi in sync with Linux
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.