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

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