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 <he...@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. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
