[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
Add aliases for mmc controller to get a fixed order with emmc at index 0 and sdmmc at index 1.
Signed-off-by: Kever Yang kever.yang@rock-chips.com ---
arch/arm/dts/rk3328.dtsi | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi index 8a98ee3..e1af030 100644 --- a/arch/arm/dts/rk3328.dtsi +++ b/arch/arm/dts/rk3328.dtsi @@ -25,6 +25,9 @@ i2c1 = &i2c1; i2c2 = &i2c2; i2c3 = &i2c3; + mmc0 = &emmc; + mmc1 = &sdmmc; + mmc2 = &sdmmc_ext; };
cpus {
On 18 May 2017 at 02:05, Kever Yang kever.yang@rock-chips.com wrote:
Add aliases for mmc controller to get a fixed order with emmc at index 0 and sdmmc at index 1.
Signed-off-by: Kever Yang kever.yang@rock-chips.com
arch/arm/dts/rk3328.dtsi | 3 +++ 1 file changed, 3 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org
Simon,
After the long discuss, this patch can be applied without any update, right?
Thanks, - Kever On 05/23/2017 04:26 AM, Simon Glass wrote:
On 18 May 2017 at 02:05, Kever Yang kever.yang@rock-chips.com wrote:
Add aliases for mmc controller to get a fixed order with emmc at index 0 and sdmmc at index 1.
Signed-off-by: Kever Yang kever.yang@rock-chips.com
arch/arm/dts/rk3328.dtsi | 3 +++ 1 file changed, 3 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org
Hi Kever,
On 8 June 2017 at 18:48, Kever Yang kever.yang@rock-chips.com wrote:
Simon,
After the long discuss, this patch can be applied without any update,right?
OK I've resurrected it in patchwork:
http://patchwork.ozlabs.org/patch/763856/
Regards, Simon
Thanks,
- Kever
On 05/23/2017 04:26 AM, Simon Glass wrote:
On 18 May 2017 at 02:05, Kever Yang kever.yang@rock-chips.com wrote:
Add aliases for mmc controller to get a fixed order with emmc at index 0 and sdmmc at index 1.
Signed-off-by: Kever Yang kever.yang@rock-chips.com
arch/arm/dts/rk3328.dtsi | 3 +++ 1 file changed, 3 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org
Hi Kever,
On 8 June 2017 at 18:48, Kever Yang kever.yang@rock-chips.com wrote:
Simon,
After the long discuss, this patch can be applied without any update,right?
OK I've resurrected it in patchwork:
http://patchwork.ozlabs.org/patch/763856/
Regards, Simon
Thanks,
- Kever
On 05/23/2017 04:26 AM, Simon Glass wrote:
On 18 May 2017 at 02:05, Kever Yang kever.yang@rock-chips.com wrote:
Add aliases for mmc controller to get a fixed order with emmc at index 0 and sdmmc at index 1.
Signed-off-by: Kever Yang kever.yang@rock-chips.com
arch/arm/dts/rk3328.dtsi | 3 +++ 1 file changed, 3 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org
Applied to u-boot-dm, thanks!
On Thu, May 18, 2017 at 04:05:20PM +0800, Kever Yang wrote:
Add aliases for mmc controller to get a fixed order with emmc at index 0 and sdmmc at index 1.
Signed-off-by: Kever Yang kever.yang@rock-chips.com
arch/arm/dts/rk3328.dtsi | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi index 8a98ee3..e1af030 100644 --- a/arch/arm/dts/rk3328.dtsi +++ b/arch/arm/dts/rk3328.dtsi @@ -25,6 +25,9 @@ i2c1 = &i2c1; i2c2 = &i2c2; i2c3 = &i2c3;
mmc0 = &emmc;mmc1 = &sdmmc;mmc2 = &sdmmc_ext;};
cpus {
Does this come from re-syncing the dts with the kernel? Are they going to the kernel? Thanks!
Tom,
This is not from kernel, seems the kernel mmc driver does not support aliases now,
thought I hope they both support the aliases for ordering.
Thanks, - Kever On 05/23/2017 05:18 AM, Tom Rini wrote:
On Thu, May 18, 2017 at 04:05:20PM +0800, Kever Yang wrote:
Add aliases for mmc controller to get a fixed order with emmc at index 0 and sdmmc at index 1.
Signed-off-by: Kever Yang kever.yang@rock-chips.com
arch/arm/dts/rk3328.dtsi | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi index 8a98ee3..e1af030 100644 --- a/arch/arm/dts/rk3328.dtsi +++ b/arch/arm/dts/rk3328.dtsi @@ -25,6 +25,9 @@ i2c1 = &i2c1; i2c2 = &i2c2; i2c3 = &i2c3;
mmc0 = &emmc;mmc1 = &sdmmc;mmc2 = &sdmmc_ext;};
cpus {
Does this come from re-syncing the dts with the kernel? Are they going to the kernel? Thanks!
On Tue, May 23, 2017 at 02:32:44PM +0800, Kever Yang wrote:
Tom,
This is not from kernel, seems the kernel mmc driver does notsupport aliases now,
thought I hope they both support the aliases for ordering.
Er, what do you mean exactly that the kernel mmc driver doesn't support aliases now? Did it before, and it was dropped?
Hi Kever, Tom,
Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:
This is not from kernel, seems the kernel mmc driver does notsupport aliases now,
thought I hope they both support the aliases for ordering.
there was a lengthy discussion about the pros and cons of ordering mmc devices last year [0].
With the outcome that explicit ordering via aliases is not desired and the argument being that mmc devices are not so different from usb storage or scsi/sata devices whose ordering is random all the time.
Heiko
[0] https://lkml.org/lkml/2016/4/29/621
Thanks,
- Kever
On 05/23/2017 05:18 AM, Tom Rini wrote:
On Thu, May 18, 2017 at 04:05:20PM +0800, Kever Yang wrote:
Add aliases for mmc controller to get a fixed order with emmc at index 0 and sdmmc at index 1.
Signed-off-by: Kever Yang kever.yang@rock-chips.com
arch/arm/dts/rk3328.dtsi | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi index 8a98ee3..e1af030 100644 --- a/arch/arm/dts/rk3328.dtsi +++ b/arch/arm/dts/rk3328.dtsi @@ -25,6 +25,9 @@ i2c1 = &i2c1; i2c2 = &i2c2; i2c3 = &i2c3;
mmc0 = &emmc;mmc1 = &sdmmc;mmc2 = &sdmmc_ext;};
cpus {
Does this come from re-syncing the dts with the kernel? Are they going to the kernel? Thanks!
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On Tue, May 23, 2017 at 10:29:33PM +0200, Heiko Stuebner wrote:
Hi Kever, Tom,
Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:
This is not from kernel, seems the kernel mmc driver does notsupport aliases now,
thought I hope they both support the aliases for ordering.
there was a lengthy discussion about the pros and cons of ordering mmc devices last year [0].
With the outcome that explicit ordering via aliases is not desired and the argument being that mmc devices are not so different from usb storage or scsi/sata devices whose ordering is random all the time.
Ug, that's right. This at least needs to go into the -u-boot.dtsi file then and we can see if we can do anything else (probably not) to ensure sanity with respect to ordering.
From: Heiko Stuebner heiko@sntech.de Date: Tue, 23 May 2017 22:29:33 +0200
Hi Kever, Tom,
Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:
This is not from kernel, seems the kernel mmc driver does notsupport aliases now,
thought I hope they both support the aliases for ordering.
there was a lengthy discussion about the pros and cons of ordering mmc devices last year [0].
With the outcome that explicit ordering via aliases is not desired and the argument being that mmc devices are not so different from usb storage or scsi/sata devices whose ordering is random all the time.
Aren't you intepreting the outcome of that discussion a bit too broadly tough? That discussion seems to reject an explicit ordering of mmc device names in the Linux kernel, mainly because better mechanisms exist to refer to a particular device than its device name/number. But that doesn't preclude having a meaningful set of aliases for certain boards if there is some sort of canonical boot order or if devices are actually numbered on a board?
In OpenFirmware the primary purpose of these aliases is to specify which device to boot from.
On Tue, May 23, 2017 at 11:03:23PM +0200, Mark Kettenis wrote:
From: Heiko Stuebner heiko@sntech.de Date: Tue, 23 May 2017 22:29:33 +0200
Hi Kever, Tom,
Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:
This is not from kernel, seems the kernel mmc driver does notsupport aliases now,
thought I hope they both support the aliases for ordering.
there was a lengthy discussion about the pros and cons of ordering mmc devices last year [0].
With the outcome that explicit ordering via aliases is not desired and the argument being that mmc devices are not so different from usb storage or scsi/sata devices whose ordering is random all the time.
Aren't you intepreting the outcome of that discussion a bit too broadly tough? That discussion seems to reject an explicit ordering of mmc device names in the Linux kernel, mainly because better mechanisms exist to refer to a particular device than its device name/number. But that doesn't preclude having a meaningful set of aliases for certain boards if there is some sort of canonical boot order or if devices are actually numbered on a board?
In OpenFirmware the primary purpose of these aliases is to specify which device to boot from.
Rob?
Hi,
Am Dienstag, 23. Mai 2017, 17:14:19 CEST schrieb Tom Rini:
On Tue, May 23, 2017 at 11:03:23PM +0200, Mark Kettenis wrote:
From: Heiko Stuebner heiko@sntech.de Date: Tue, 23 May 2017 22:29:33 +0200
Hi Kever, Tom,
Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:
This is not from kernel, seems the kernel mmc driver does notsupport aliases now,
thought I hope they both support the aliases for ordering.
there was a lengthy discussion about the pros and cons of ordering mmc devices last year [0].
With the outcome that explicit ordering via aliases is not desired and the argument being that mmc devices are not so different from usb storage or scsi/sata devices whose ordering is random all the time.
Aren't you intepreting the outcome of that discussion a bit too broadly tough? That discussion seems to reject an explicit ordering of mmc device names in the Linux kernel, mainly because better mechanisms exist to refer to a particular device than its device name/number. But that doesn't preclude having a meaningful set of aliases for certain boards if there is some sort of canonical boot order or if devices are actually numbered on a board?
In OpenFirmware the primary purpose of these aliases is to specify which device to boot from.
readding the lkml-link for the above: [0] https://lkml.org/lkml/2016/4/29/621
As for that being to broad, wasn't that why Tom suggested moving that to a -u-boot.dtsi file, because while generally not desired, it may benefit uboot to get some sane boot order / type marks (emmc, sd-card), but doesn't influence the core devicetree files that should ideally be synced from the kernel or wherever?
Heiko
Hi Heiko,
Am 23.05.2017 um 23:27 schrieb Heiko Stuebner:
Am Dienstag, 23. Mai 2017, 17:14:19 CEST schrieb Tom Rini:
On Tue, May 23, 2017 at 11:03:23PM +0200, Mark Kettenis wrote:
From: Heiko Stuebner heiko@sntech.de Date: Tue, 23 May 2017 22:29:33 +0200
Hi Kever, Tom,
Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:
This is not from kernel, seems the kernel mmc driver does notsupport aliases now,
thought I hope they both support the aliases for ordering.
there was a lengthy discussion about the pros and cons of ordering mmc devices last year [0].
With the outcome that explicit ordering via aliases is not desired and the argument being that mmc devices are not so different from usb storage or scsi/sata devices whose ordering is random all the time.
Aren't you intepreting the outcome of that discussion a bit too broadly tough? That discussion seems to reject an explicit ordering of mmc device names in the Linux kernel, mainly because better mechanisms exist to refer to a particular device than its device name/number. But that doesn't preclude having a meaningful set of aliases for certain boards if there is some sort of canonical boot order or if devices are actually numbered on a board?
In OpenFirmware the primary purpose of these aliases is to specify which device to boot from.
readding the lkml-link for the above: [0] https://lkml.org/lkml/2016/4/29/621
As for that being to broad, wasn't that why Tom suggested moving that to a -u-boot.dtsi file, because while generally not desired, it may benefit uboot to get some sane boot order / type marks (emmc, sd-card), but doesn't influence the core devicetree files that should ideally be synced from the kernel or wherever?
I think you're mixing three very distinct topics here: a) Whether Linux drivers should use aliases for ordering. b) Whether to add aliases in the DT. c) Sync'ing .dts files from Linux vs. local changes.
I don't see what's wrong with b) as it is useful as a shorthand for access to a particular node, e.g. for U-Boot's fdt commands.
Tom's point is that if a certain change is not in the Linux .dts and is needed for U-Boot, it should go into a U-Boot specific .dtsi file, so that the change doesn't get overwritten with the next .dts update from Linux. In the UEFI boot path we rely on a recent upstream-compatible DT being provided by U-Boot if none is installed by the OS in a way U-Boot can load, so the .dts will need to be re-sync'ed later on even if it doesn't affect U-Boot drivers. Therefore the commit messages also need to indicate where the .dts comes from, to avoid regressions on re-sync from different trees.
Regards, Andreas
Hi,
On 23 May 2017 at 16:18, Andreas Färber afaerber@suse.de wrote:
Hi Heiko,
Am 23.05.2017 um 23:27 schrieb Heiko Stuebner:
Am Dienstag, 23. Mai 2017, 17:14:19 CEST schrieb Tom Rini:
On Tue, May 23, 2017 at 11:03:23PM +0200, Mark Kettenis wrote:
From: Heiko Stuebner heiko@sntech.de Date: Tue, 23 May 2017 22:29:33 +0200
Hi Kever, Tom,
Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:
This is not from kernel, seems the kernel mmc driver does notsupport aliases now,
thought I hope they both support the aliases for ordering.
there was a lengthy discussion about the pros and cons of ordering mmc devices last year [0].
With the outcome that explicit ordering via aliases is not desired and the argument being that mmc devices are not so different from usb storage or scsi/sata devices whose ordering is random all the time.
Aren't you intepreting the outcome of that discussion a bit too broadly tough? That discussion seems to reject an explicit ordering of mmc device names in the Linux kernel, mainly because better mechanisms exist to refer to a particular device than its device name/number. But that doesn't preclude having a meaningful set of aliases for certain boards if there is some sort of canonical boot order or if devices are actually numbered on a board?
In OpenFirmware the primary purpose of these aliases is to specify which device to boot from.
readding the lkml-link for the above: [0] https://lkml.org/lkml/2016/4/29/621
As for that being to broad, wasn't that why Tom suggested moving that to a -u-boot.dtsi file, because while generally not desired, it may benefit uboot to get some sane boot order / type marks (emmc, sd-card), but doesn't influence the core devicetree files that should ideally be synced from the kernel or wherever?
I think you're mixing three very distinct topics here: a) Whether Linux drivers should use aliases for ordering. b) Whether to add aliases in the DT. c) Sync'ing .dts files from Linux vs. local changes.
I don't see what's wrong with b) as it is useful as a shorthand for access to a particular node, e.g. for U-Boot's fdt commands.
Tom's point is that if a certain change is not in the Linux .dts and is needed for U-Boot, it should go into a U-Boot specific .dtsi file, so that the change doesn't get overwritten with the next .dts update from Linux. In the UEFI boot path we rely on a recent upstream-compatible DT being provided by U-Boot if none is installed by the OS in a way U-Boot can load, so the .dts will need to be re-sync'ed later on even if it doesn't affect U-Boot drivers. Therefore the commit messages also need to indicate where the .dts comes from, to avoid regressions on re-sync from different trees.
Further to that, I think U-Boot needs the aliases because we refer to devices by number.
At a future date if U-Boot moves away from this to named devices, we can revisit it.
But so far as I can tell, without the aliases, U-Boot cannot operate in a reliable, repeatable manner.
Regards, Simon
Am Dienstag, 23. Mai 2017, 18:44:37 CEST schrieb Simon Glass:
Hi,
On 23 May 2017 at 16:18, Andreas Färber afaerber@suse.de wrote:
Hi Heiko,
Am 23.05.2017 um 23:27 schrieb Heiko Stuebner:
Am Dienstag, 23. Mai 2017, 17:14:19 CEST schrieb Tom Rini:
On Tue, May 23, 2017 at 11:03:23PM +0200, Mark Kettenis wrote:
From: Heiko Stuebner heiko@sntech.de Date: Tue, 23 May 2017 22:29:33 +0200
Hi Kever, Tom,
Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang: > This is not from kernel, seems the kernel mmc driver does not > support aliases now, > > thought I hope they both support the aliases for ordering.
there was a lengthy discussion about the pros and cons of ordering mmc devices last year [0].
With the outcome that explicit ordering via aliases is not desired and the argument being that mmc devices are not so different from usb storage or scsi/sata devices whose ordering is random all the time.
Aren't you intepreting the outcome of that discussion a bit too broadly tough? That discussion seems to reject an explicit ordering of mmc device names in the Linux kernel, mainly because better mechanisms exist to refer to a particular device than its device name/number. But that doesn't preclude having a meaningful set of aliases for certain boards if there is some sort of canonical boot order or if devices are actually numbered on a board?
In OpenFirmware the primary purpose of these aliases is to specify which device to boot from.
readding the lkml-link for the above: [0] https://lkml.org/lkml/2016/4/29/621
As for that being to broad, wasn't that why Tom suggested moving that to a -u-boot.dtsi file, because while generally not desired, it may benefit uboot to get some sane boot order / type marks (emmc, sd-card), but doesn't influence the core devicetree files that should ideally be synced from the kernel or wherever?
I think you're mixing three very distinct topics here: a) Whether Linux drivers should use aliases for ordering. b) Whether to add aliases in the DT. c) Sync'ing .dts files from Linux vs. local changes.
I don't see what's wrong with b) as it is useful as a shorthand for access to a particular node, e.g. for U-Boot's fdt commands.
Tom's point is that if a certain change is not in the Linux .dts and is needed for U-Boot, it should go into a U-Boot specific .dtsi file, so that the change doesn't get overwritten with the next .dts update from Linux. In the UEFI boot path we rely on a recent upstream-compatible DT being provided by U-Boot if none is installed by the OS in a way U-Boot can load, so the .dts will need to be re-sync'ed later on even if it doesn't affect U-Boot drivers. Therefore the commit messages also need to indicate where the .dts comes from, to avoid regressions on re-sync from different trees.
Further to that, I think U-Boot needs the aliases because we refer to devices by number.
At a future date if U-Boot moves away from this to named devices, we can revisit it.
But so far as I can tell, without the aliases, U-Boot cannot operate in a reliable, repeatable manner.
ok, then never mind. You people probably know better what makes sense in an u-boot context :-) .
Heiko
On Wed, May 24, 2017 at 10:18:12AM +0200, Heiko Stuebner wrote:
Am Dienstag, 23. Mai 2017, 18:44:37 CEST schrieb Simon Glass:
Hi,
On 23 May 2017 at 16:18, Andreas Färber afaerber@suse.de wrote:
Hi Heiko,
Am 23.05.2017 um 23:27 schrieb Heiko Stuebner:
Am Dienstag, 23. Mai 2017, 17:14:19 CEST schrieb Tom Rini:
On Tue, May 23, 2017 at 11:03:23PM +0200, Mark Kettenis wrote:
> From: Heiko Stuebner heiko@sntech.de > Date: Tue, 23 May 2017 22:29:33 +0200 > > Hi Kever, Tom, > > Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang: >> This is not from kernel, seems the kernel mmc driver does not >> support aliases now, >> >> thought I hope they both support the aliases for ordering. > > there was a lengthy discussion about the pros and cons of ordering > mmc devices last year [0]. > > With the outcome that explicit ordering via aliases is not desired > and the argument being that mmc devices are not so different from > usb storage or scsi/sata devices whose ordering is random all the time.
Aren't you intepreting the outcome of that discussion a bit too broadly tough? That discussion seems to reject an explicit ordering of mmc device names in the Linux kernel, mainly because better mechanisms exist to refer to a particular device than its device name/number. But that doesn't preclude having a meaningful set of aliases for certain boards if there is some sort of canonical boot order or if devices are actually numbered on a board?
In OpenFirmware the primary purpose of these aliases is to specify which device to boot from.
readding the lkml-link for the above: [0] https://lkml.org/lkml/2016/4/29/621
As for that being to broad, wasn't that why Tom suggested moving that to a -u-boot.dtsi file, because while generally not desired, it may benefit uboot to get some sane boot order / type marks (emmc, sd-card), but doesn't influence the core devicetree files that should ideally be synced from the kernel or wherever?
I think you're mixing three very distinct topics here: a) Whether Linux drivers should use aliases for ordering. b) Whether to add aliases in the DT. c) Sync'ing .dts files from Linux vs. local changes.
I don't see what's wrong with b) as it is useful as a shorthand for access to a particular node, e.g. for U-Boot's fdt commands.
Tom's point is that if a certain change is not in the Linux .dts and is needed for U-Boot, it should go into a U-Boot specific .dtsi file, so that the change doesn't get overwritten with the next .dts update from Linux. In the UEFI boot path we rely on a recent upstream-compatible DT being provided by U-Boot if none is installed by the OS in a way U-Boot can load, so the .dts will need to be re-sync'ed later on even if it doesn't affect U-Boot drivers. Therefore the commit messages also need to indicate where the .dts comes from, to avoid regressions on re-sync from different trees.
Further to that, I think U-Boot needs the aliases because we refer to devices by number.
At a future date if U-Boot moves away from this to named devices, we can revisit it.
But so far as I can tell, without the aliases, U-Boot cannot operate in a reliable, repeatable manner.
ok, then never mind. You people probably know better what makes sense in an u-boot context :-) .
Yeah, but it's one of those things I don't quite understand about why we need to put non-project-specific (ie it's not a u-boot,xxx thing) into our spot to append the dts. If we're talking about good, valid DT content (ie nearly every SoC manual I've seen says MMC1 is ..., MMC2 is ..., etc, so it's hardware description) why can't it be in the upstream dts file and simply ignored by the kernel if it doesn't want it?
Hi Tom,
On 24 May 2017 at 06:56, Tom Rini trini@konsulko.com wrote:
On Wed, May 24, 2017 at 10:18:12AM +0200, Heiko Stuebner wrote:
Am Dienstag, 23. Mai 2017, 18:44:37 CEST schrieb Simon Glass:
Hi,
On 23 May 2017 at 16:18, Andreas Färber afaerber@suse.de wrote:
Hi Heiko,
Am 23.05.2017 um 23:27 schrieb Heiko Stuebner:
Am Dienstag, 23. Mai 2017, 17:14:19 CEST schrieb Tom Rini:
On Tue, May 23, 2017 at 11:03:23PM +0200, Mark Kettenis wrote: >> From: Heiko Stuebner heiko@sntech.de >> Date: Tue, 23 May 2017 22:29:33 +0200 >> >> Hi Kever, Tom, >> >> Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang: >>> This is not from kernel, seems the kernel mmc driver does not >>> support aliases now, >>> >>> thought I hope they both support the aliases for ordering. >> >> there was a lengthy discussion about the pros and cons of ordering >> mmc devices last year [0]. >> >> With the outcome that explicit ordering via aliases is not desired >> and the argument being that mmc devices are not so different from >> usb storage or scsi/sata devices whose ordering is random all the time. > > Aren't you intepreting the outcome of that discussion a bit too > broadly tough? That discussion seems to reject an explicit ordering > of mmc device names in the Linux kernel, mainly because better > mechanisms exist to refer to a particular device than its device > name/number. But that doesn't preclude having a meaningful set of > aliases for certain boards if there is some sort of canonical boot > order or if devices are actually numbered on a board? > > In OpenFirmware the primary purpose of these aliases is to specify > which device to boot from.
readding the lkml-link for the above: [0] https://lkml.org/lkml/2016/4/29/621
As for that being to broad, wasn't that why Tom suggested moving that to a -u-boot.dtsi file, because while generally not desired, it may benefit uboot to get some sane boot order / type marks (emmc, sd-card), but doesn't influence the core devicetree files that should ideally be synced from the kernel or wherever?
I think you're mixing three very distinct topics here: a) Whether Linux drivers should use aliases for ordering. b) Whether to add aliases in the DT. c) Sync'ing .dts files from Linux vs. local changes.
I don't see what's wrong with b) as it is useful as a shorthand for access to a particular node, e.g. for U-Boot's fdt commands.
Tom's point is that if a certain change is not in the Linux .dts and is needed for U-Boot, it should go into a U-Boot specific .dtsi file, so that the change doesn't get overwritten with the next .dts update from Linux. In the UEFI boot path we rely on a recent upstream-compatible DT being provided by U-Boot if none is installed by the OS in a way U-Boot can load, so the .dts will need to be re-sync'ed later on even if it doesn't affect U-Boot drivers. Therefore the commit messages also need to indicate where the .dts comes from, to avoid regressions on re-sync from different trees.
Further to that, I think U-Boot needs the aliases because we refer to devices by number.
At a future date if U-Boot moves away from this to named devices, we can revisit it.
But so far as I can tell, without the aliases, U-Boot cannot operate in a reliable, repeatable manner.
ok, then never mind. You people probably know better what makes sense in an u-boot context :-) .
Yeah, but it's one of those things I don't quite understand about why we need to put non-project-specific (ie it's not a u-boot,xxx thing) into our spot to append the dts. If we're talking about good, valid DT content (ie nearly every SoC manual I've seen says MMC1 is ..., MMC2 is ..., etc, so it's hardware description) why can't it be in the upstream dts file and simply ignored by the kernel if it doesn't want it?
I agree that makes sense. I cannot think of a reason that the DT should be restricted to contain things only useful to Linux.
Regards, Simon
participants (7)
-
Andreas Färber -
Heiko Stuebner -
Kever Yang -
Mark Kettenis -
Simon Glass -
sjg＠google.com -
Tom Rini