On Wednesday, December 7, 2022 3:03:56 P.M. EST Tom Rini wrote:
On Mon, Dec 05, 2022 at 02:33:48PM -0300, Fabio Estevam wrote:
On Mon, Dec 5, 2022 at 12:37 PM Tom Rini trini@konsulko.com wrote:
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?
imx6q.dtsi does have the default mmc aliases:
mmc0 = &usdhc1; mmc1 = &usdhc2; mmc2 = &usdhc3; mmc3 = &usdhc4;
Upstream does not want to change mmc alias because users may rely on this mmc aliases.
Changing it now may cause the board not to boot anymore as the rootfs cannot be found.
It is OK to change mmc alias for a newly introduced board, but please keep in mind that wandboard and sabrelite have been launched many many years ago.
So for upstream Linux the message was clear: don't change the mmc alias for these boards.
Now let's talk about U-Boot.
Prior to d0399a46e7cd ("imx6dl/imx6qdl: synchronise device trees with
linux") the mmc alias for sabrelite was present: mmc0 = &usdhc3; mmc1 = &usdhc4;
After this commit, the mmc alias is gone and causes the boot regression as reported by Detlev.
We don't want to cause regressions in U-Boot as well, so that's why I propose just adding the alias into u-boot.dtsi.
There are many boards that does the same.
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
imx6 dts files are already synced with Linux.
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.
I prefer to not break things for anyone, hence my proposal.
If you are still not happy with it, please feel free to submit a patch with your proposal.
I don't know what we can do about the existing boards, but we need to NOT do this moving forward. We need to use whatever the aliases are upstream already, or upstream the aliases we want to use.
Yes, I agree that aliases should be kept in sync with the kernel. But this case is particular because this board has been using different aliases in u- boot and in linux for some time (maybe since forever).
So this should be kept to avoid breaking existing u-boot setups when they are upgraded.