From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Stuebner Date: Tue, 23 May 2017 23:27:26 +0200 Subject: [U-Boot] [PATCH] rockchip: dts: rk3328: add aliases for mmc controller In-Reply-To: <20170523211419.GQ23727@bill-the-cat> References: <1495094720-27739-1-git-send-email-kever.yang@rock-chips.com> <201705232103.v4NL3NTh017815@glazunov.sibelius.xs4all.nl> <20170523211419.GQ23727@bill-the-cat> Message-ID: <1969746.8ixlS7VFTt@phil> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, 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 > > > 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? Heiko