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 <[email protected]>

---

 arch/arm/dts/rk3328.dtsi | 3 +++
 1 file changed, 3 insertions(+)

Quoted 8 lines · Kever Yang

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 <[email protected]>

---

  arch/arm/dts/rk3328.dtsi | 3 +++
  1 file changed, 3 insertions(+)

Reviewed-by Simon Glass <[email protected]>

Simon,

After the long discuss, this patch can be applied without any update,
right?

Thanks,
- Kever

Quoted 14 lines · Simon Glass

Quoted 9 lines · Kever Yang

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 <[email protected]>

---

  arch/arm/dts/rk3328.dtsi | 3 +++
  1 file changed, 3 insertions(+)

Reviewed-by Simon Glass <[email protected]>

Simon,

After the long discuss, this patch can be applied without any update,
right?

Thanks,
- Kever

Quoted 14 lines · Simon Glass

Quoted 9 lines · Kever Yang

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 <[email protected]>

---

  arch/arm/dts/rk3328.dtsi | 3 +++
  1 file changed, 3 insertions(+)

Reviewed-by Simon Glass <[email protected]>

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 <[email protected]>

---

 arch/arm/dts/rk3328.dtsi | 3 +++
 1 file changed, 3 insertions(+)

arch/arm/dts/rk3328.dtsi +0 -0

index 8a98ee3..e1af030 100644

Quoted 14 lines · Kever Yang

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 <[email protected]>

---

  arch/arm/dts/rk3328.dtsi | 3 +++
  1 file changed, 3 insertions(+)

arch/arm/dts/rk3328.dtsi +0 -0

index 8a98ee3..e1af030 100644

arch/arm/dts/rk3328.dtsi line 33

Quoted 9 lines

arch/arm/dts/rk3328.dtsi +3 -0

@@ -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.

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

Quoted 24 lines · Tom Rini

Quoted 22 lines · Kever Yang

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 <[email protected]>

---

  arch/arm/dts/rk3328.dtsi | 3 +++
  1 file changed, 3 insertions(+)

arch/arm/dts/rk3328.dtsi +3 -0

index 8a98ee3..e1af030 100644
@@ -25,6 +25,9 @@
  		i2c1 = &i2c1;
  		i2c2 = &i2c2;
  		i2c3 = &i2c3;
+		mmc0 = &emmc;
+		mmc1 = &sdmmc;
+		mmc2 = &sdmmc_ext;
  	};
 

Quoted 4 lines

arch/arm/dts/rk3328.dtsi line 33

Quoted 1 line

arch/arm/dts/rk3328.dtsi +0 -0

  	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 at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Hi Kever, Tom,

Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:

Quoted 3 lines

This is not from kernel, seems the kernel mmc driver does not
support aliases now,

Quoted 1 line

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.

From: Heiko Stuebner <[email protected]>
Date: Tue, 23 May 2017 22:29:33 +0200

Hi Kever, Tom,

Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:

Quoted 3 lines

This is not from kernel, seems the kernel mmc driver does not
support aliases now,

Quoted 1 line

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.

Quoted 9 lines

From: Heiko Stuebner <[email protected]>
Date: Tue, 23 May 2017 22:29:33 +0200

Hi Kever, Tom,

Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:

Quoted 3 lines

This is not from kernel, seems the kernel mmc driver does not
support aliases now,

Quoted 8 lines

Quoted 1 line

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.

Quoted 26 lines

Quoted 9 lines

From: Heiko Stuebner <[email protected]>
Date: Tue, 23 May 2017 22:29:33 +0200

Hi Kever, Tom,

Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:

Quoted 3 lines

This is not from kernel, seems the kernel mmc driver does not
support aliases now,

Quoted 8 lines

Quoted 1 line

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?

Quoted 2 lines

In OpenFirmware the primary purpose of these aliases is to specify which device to boot from.

Am Dienstag, 23. Mai 2017, 17:14:19 CEST schrieb Tom Rini:

Quoted 27 lines · Mark Kettenis

Quoted 26 lines

Quoted 9 lines

From: Heiko Stuebner <[email protected]>
Date: Tue, 23 May 2017 22:29:33 +0200

Hi Kever, Tom,

Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:

Quoted 3 lines

This is not from kernel, seems the kernel mmc driver does not
support aliases now,

Quoted 8 lines

Quoted 1 line

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?

Quoted 2 lines

Quoted 2 lines

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?

Hi Heiko,

Am 23.05.2017 um 23:27 schrieb Heiko Stuebner:

Quoted 35 lines

Am Dienstag, 23. Mai 2017, 17:14:19 CEST schrieb Tom Rini:

Quoted 27 lines · Mark Kettenis

Quoted 26 lines

Quoted 9 lines

From: Heiko Stuebner <[email protected]>
Date: Tue, 23 May 2017 22:29:33 +0200

Hi Kever, Tom,

Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:

Quoted 3 lines

This is not from kernel, seems the kernel mmc driver does not
support aliases now,

Quoted 8 lines

Quoted 1 line

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?

Quoted 2 lines

Quoted 2 lines

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

Quoted 5 lines

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.

Hi,

Quoted 52 lines · Andreas Färber

Hi Heiko,

Am 23.05.2017 um 23:27 schrieb Heiko Stuebner:

Quoted 35 lines

Am Dienstag, 23. Mai 2017, 17:14:19 CEST schrieb Tom Rini:

Quoted 27 lines · Mark Kettenis

Quoted 26 lines

Quoted 9 lines

From: Heiko Stuebner <[email protected]>
Date: Tue, 23 May 2017 22:29:33 +0200

Hi Kever, Tom,

Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:

Quoted 3 lines

This is not from kernel, seems the kernel mmc driver does not
support aliases now,

Quoted 8 lines

Quoted 1 line

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?

Quoted 2 lines

Quoted 2 lines

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

Quoted 5 lines

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.

Quoted 10 lines

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.

Am Dienstag, 23. Mai 2017, 18:44:37 CEST schrieb Simon Glass:

Quoted 69 lines

Hi,

Quoted 52 lines · Andreas Färber

Hi Heiko,

Am 23.05.2017 um 23:27 schrieb Heiko Stuebner:

Quoted 35 lines

Am Dienstag, 23. Mai 2017, 17:14:19 CEST schrieb Tom Rini:

Quoted 27 lines · Mark Kettenis

Quoted 26 lines

Quoted 9 lines

From: Heiko Stuebner <[email protected]>
Date: Tue, 23 May 2017 22:29:33 +0200

Hi Kever, Tom,

Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:

Quoted 3 lines

This is not from kernel, seems the kernel mmc driver does not
support aliases now,

Quoted 8 lines

Quoted 1 line

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?

Quoted 2 lines

Quoted 2 lines

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

Quoted 5 lines

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.

Quoted 10 lines

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.

Quoted 5 lines

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 :-) .

Quoted 70 lines · Heiko Stuebner

Am Dienstag, 23. Mai 2017, 18:44:37 CEST schrieb Simon Glass:

Quoted 69 lines

Hi,

Quoted 52 lines · Andreas Färber

Hi Heiko,

Am 23.05.2017 um 23:27 schrieb Heiko Stuebner:

Quoted 35 lines

Am Dienstag, 23. Mai 2017, 17:14:19 CEST schrieb Tom Rini:

Quoted 27 lines · Mark Kettenis

Quoted 26 lines

Quoted 9 lines

From: Heiko Stuebner <[email protected]>
Date: Tue, 23 May 2017 22:29:33 +0200

Hi Kever, Tom,

Am Dienstag, 23. Mai 2017, 14:32:44 CEST schrieb Kever Yang:

Quoted 3 lines

This is not from kernel, seems the kernel mmc driver does not
support aliases now,

Quoted 8 lines

Quoted 1 line

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?

Quoted 2 lines

Quoted 2 lines

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

Quoted 5 lines

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.

Quoted 10 lines

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.

Quoted 8 lines

Quoted 5 lines

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?