From: Michael Riesch <hidden> Date: 2021-09-17 11:06:06
In order to ensure deterministic probe order over different boards,
move the aliases of on-SoC components to the corresponding dtsi
files.
Signed-off-by: Michael Riesch <redacted>
---
arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts | 6 ------
arch/arm64/boot/dts/rockchip/rk3566.dtsi | 4 ++++
arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts | 7 -------
arch/arm64/boot/dts/rockchip/rk3568.dtsi | 5 +++++
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 2 ++
5 files changed, 11 insertions(+), 13 deletions(-)
Hi Michael,
Am Freitag, 17. September 2021, 13:05:28 CEST schrieb Michael Riesch:
In order to ensure deterministic probe order over different boards,
move the aliases of on-SoC components to the corresponding dtsi
files.
please read the git history on the other Rockchip SoCs. We just moved
the aliases on them _to_ the board-files, as requested by
arm-soc maintainers ;-)
Heiko
From: Michael Riesch <hidden> Date: 2021-09-17 12:09:26
Hi Heiko,
On 9/17/21 2:01 PM, Heiko Stübner wrote:
Hi Michael,
Am Freitag, 17. September 2021, 13:05:28 CEST schrieb Michael Riesch:
quoted
In order to ensure deterministic probe order over different boards,
move the aliases of on-SoC components to the corresponding dtsi
files.
please read the git history on the other Rockchip SoCs. We just moved
the aliases on them _to_ the board-files, as requested by
arm-soc maintainers ;-)
OK, I was not aware of this. Some SoC families (e.g., Freescale IMX)
have those aliases in the dtsi and I was not sure what the desired
approach was. Thanks for the clarification.
Best regards,
Michael
From: Ahmad Fatoum <a.fatoum@pengutronix.de> Date: 2021-09-22 13:41:09
Hello Heiko,
On 17.09.21 14:01, Heiko Stübner wrote:
Hi Michael,
Am Freitag, 17. September 2021, 13:05:28 CEST schrieb Michael Riesch:
quoted
In order to ensure deterministic probe order over different boards,
move the aliases of on-SoC components to the corresponding dtsi
files.
please read the git history on the other Rockchip SoCs. We just moved
the aliases on them _to_ the board-files, as requested by
arm-soc maintainers ;-)
[Adding Arnd to CC]
For old boards, changing the aliases may introduce breakage that outweighs
the benefit of having consistent numbering. This doesn't seem to apply here:
rk3566.dtsi is a new device tree not yet in v5.15-rc2 and rk3568 is new in
v5.14 and has only one board partially supported, so if we were to do this
change we should do it now. Boards will still be free to override the aliases,
but those that don't will have consistent numbering regardless of whether
nodes are enabled, cards are detected or probe order.
Cheers,
Ahmad
Hi Ahmad,
Am Mittwoch, 22. September 2021, 15:40:33 CEST schrieb Ahmad Fatoum:
Hello Heiko,
On 17.09.21 14:01, Heiko Stübner wrote:
quoted
Hi Michael,
Am Freitag, 17. September 2021, 13:05:28 CEST schrieb Michael Riesch:
quoted
In order to ensure deterministic probe order over different boards,
move the aliases of on-SoC components to the corresponding dtsi
files.
please read the git history on the other Rockchip SoCs. We just moved
the aliases on them _to_ the board-files, as requested by
arm-soc maintainers ;-)
[Adding Arnd to CC]
For old boards, changing the aliases may introduce breakage that outweighs
the benefit of having consistent numbering. This doesn't seem to apply here:
rk3566.dtsi is a new device tree not yet in v5.15-rc2 and rk3568 is new in
v5.14 and has only one board partially supported, so if we were to do this
change we should do it now. Boards will still be free to override the aliases,
but those that don't will have consistent numbering regardless of whether
nodes are enabled, cards are detected or probe order.
the request from Arnd was actually to move things like mmc aliases _to_
board files away from the soc-level dtsi. Supposedly to prevent holes in
the numbering for example if the sdmmc is mmc0, emmc is mmc1,
but sdmmc not used on a board, which would then leave mmc0 empty .
Heiko
From: Ahmad Fatoum <a.fatoum@pengutronix.de> Date: 2021-09-23 19:49:11
Hello Heiko,
On 22.09.21 18:51, Heiko Stübner wrote:
Hi Ahmad,
Am Mittwoch, 22. September 2021, 15:40:33 CEST schrieb Ahmad Fatoum:
quoted
Hello Heiko,
On 17.09.21 14:01, Heiko Stübner wrote:
quoted
Hi Michael,
Am Freitag, 17. September 2021, 13:05:28 CEST schrieb Michael Riesch:
quoted
In order to ensure deterministic probe order over different boards,
move the aliases of on-SoC components to the corresponding dtsi
files.
please read the git history on the other Rockchip SoCs. We just moved
the aliases on them _to_ the board-files, as requested by
arm-soc maintainers ;-)
[Adding Arnd to CC]
For old boards, changing the aliases may introduce breakage that outweighs
the benefit of having consistent numbering. This doesn't seem to apply here:
rk3566.dtsi is a new device tree not yet in v5.15-rc2 and rk3568 is new in
v5.14 and has only one board partially supported, so if we were to do this
change we should do it now. Boards will still be free to override the aliases,
but those that don't will have consistent numbering regardless of whether
nodes are enabled, cards are detected or probe order.
the request from Arnd was actually to move things like mmc aliases _to_
board files away from the soc-level dtsi.
Yes, I understood that. But I think for new SoCs, there is a convincing
case for having them in the SoC dtsi.
Supposedly to prevent holes in
the numbering for example if the sdmmc is mmc0, emmc is mmc1,
but sdmmc not used on a board, which would then leave mmc0 empty .
Without aliases, the numbering of the MMC devices in Linux can't be relied
on. partuuids don't work when you have the same image on e.g. eMMC and SD
and initramfs may be overkill. I'd thus say it's recommended to have aliases
for every MMC described in a device tree.
Arguably, the majority of people are fine with the numbering used by the
SoC vendor and having any numbering will prevent scripts from breaking after
updates. Board vendors that mind the holes or want to renumber the MMCs can
just override the aliases on board level.
Cheers,
Ahmad