[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 --- 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 { -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
On 18 May 2017 at 02:05, 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 > --- > > arch/arm/dts/rk3328.dtsi | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
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 > --- > > 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 signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
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 --- 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
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
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 not > support 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? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
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. 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 > >> --- > >> > >> 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 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
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 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. 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. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
> From: Heiko Stuebner > 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. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
On Tue, May 23, 2017 at 11:03:23PM +0200, Mark Kettenis wrote: > > From: Heiko Stuebner > > 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. Rob? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
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 > > > 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? Heiko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
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 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. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
Hi, On 23 May 2017 at 16:18, Andreas Färber 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 > 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. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
Am Dienstag, 23. Mai 2017, 18:44:37 CEST schrieb Simon Glass: > Hi, > > On 23 May 2017 at 16:18, Andreas Färber 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 > > 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
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 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 > > > 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? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
Hi Tom, On 24 May 2017 at 06:56, Tom Rini 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 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 >> > > 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
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 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 --- arch/arm/dts/rk3328.dtsi | 3 +++ 1 file changed, 3 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
Hi Kever, On 8 June 2017 at 18:48, Kever Yang 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 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 >>> --- >>> >>> arch/arm/dts/rk3328.dtsi | 3 +++ >>> 1 file changed, 3 insertions(+) >> >> Reviewed-by: Simon Glass >> > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller
Hi Kever, On 8 June 2017 at 18:48, Kever Yang 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 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 >>> --- >>> >>> arch/arm/dts/rk3328.dtsi | 3 +++ >>> 1 file changed, 3 insertions(+) >> >> Reviewed-by: Simon Glass >> > > Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot