Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 29 April 2016 at 19:39, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> 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?

No, as that one fixes an issue for a widely deployed product (family).

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

They don't have to break *again*. He just have to convert *once* to
use UUID/PARTID which is really what most should be doing.

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux