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

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