[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[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 <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 {
-- 
1.9.1

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Simon Glass]

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>

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Kever Yang]

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

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Simon Glass]

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

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[sjg at google.com]

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!

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170522/f6c132b8/attachment.sig>

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Kever Yang]

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!
>

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170523/5ddd5f14/attachment.sig>

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Heiko Stuebner]

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

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170523/2fce5e13/attachment.sig>

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Mark Kettenis]

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

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

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

Rob?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170523/ff36bcc4/attachment.sig>

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Heiko Stuebner]

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 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] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Andreas Färber]

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.

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] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

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

Regards,
Simon

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Heiko Stuebner]

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

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170524/0dbe2f0e/attachment.sig>

[U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller

[Simon Glass]

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