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