Dear Douglas, On Thu, 28 Apr 2016 16:06:42 -0700 Douglas Anderson wrote: > This series picks patches from various different places to produce what > I consider the best solution to getting consistent mmc and mmcblk > ordering. > > Why consistent ordering and why not just use UUIDs? IMHO consistent > ordering solves a few different problems: > > 1. For poor, feeble-minded humans like me, have sane numbering for > devices helps a lot. When grepping through dmesg it's terribly handy > if a given SDMMC device has a consistent number. I know that I can > do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about > the eMMC. I know that I can do "dmesg | grep mmc1" to find info > about the SD card slot. I don't want it to matter which one probed > first, I don't want it to matter if I'm working on a variant of the > hardware that has the SD card slot disabled, and I don't want to care > what my boot device was. Worrying about what device number I got > increases my cognitive load. > > 2. There are cases where it's not trivially easy during development to > use the UUID. Specifically I work a lot with coreboot / depthcharge > as a BIOS. When configured properly, that BIOS has a nice feature to > allow you to fetch the kernel and kernel command line from TFTP by > pressing Ctrl-N. In this particular case the BIOS doesn't actually > know which disk I'd like for my root filesystem, so it's not so easy > for it to put the right UUID into the command line. For this > purpose, knowing that "mmcblk0" will always refer to eMMC is handy. > > > Jaehoon Chung (1): > Documentation: mmc: Document mmc aliases > > Stefan Agner (2): > mmc: read mmc alias from device tree > mmc: use SD/MMC host ID for block device name ID We also need this feature. Thanks so much for upstreaming the series. Jisheng > > Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++++++ > drivers/mmc/card/block.c | 3 ++- > drivers/mmc/core/host.c | 25 ++++++++++++++++++++----- > 3 files changed, 33 insertions(+), 6 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
