On Thursday 28 April 2016 16:06:42 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
>
> 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(-)
Does this mean we can revert 9aaf343 ("mmc: block: Use the mmc host
device index as the mmcblk device index") for now and wait until this
is in as well?
The commit I mention here breaks a significant number of boots
on Olof's test build setup, and it would be nice to avoid breaking
them again when we get yet another device numbering system.
Arnd
--
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
