[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 at 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)