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

[Heiko Stuebner <heiko@sntech.de>]

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