Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Marek Vasut <marex@denx.de>]

On 3/16/19 1:22 PM, Måns Rullgård wrote:
> Marek Vasut <marex@denx.de> writes:
> 
>> On 3/15/19 10:52 PM, Tim Harvey wrote:
>>> Tim Harvey - Principal Software EngineerGateworks Corporation -
>>> http://www.gateworks.com/3026 S. Higuera St. San Luis Obispo CA
>>> 93401805-781-2000
>>> On Tue, Mar 5, 2019 at 4:39 AM Måns Rullgård <mans@mansr.com> wrote:
>>>>
>>>> Douglas Anderson <dianders@chromium.org> writes:
>>>>
>>>>> 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.
>>>>>
>>>>> Changes in v2:
>>>>> - Rebased atop mmc-next
>>>>> - Stat dynamic allocation after fixed allocation; thanks Wolfram!
>>>>> - rk3288 patch new for v2
>>>>>
>>>>> Douglas Anderson (1):
>>>>>   ARM: dts: rockchip: Add mmc aliases for rk3288 platform
>>>>>
>>>>> 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 +++++++++++
>>>>>  arch/arm/boot/dts/rk3288.dtsi                 |  4 ++++
>>>>>  drivers/mmc/card/block.c                      |  2 +-
>>>>>  drivers/mmc/core/host.c                       | 17 ++++++++++++++++-
>>>>>  4 files changed, 32 insertions(+), 2 deletions(-)
>>>>
>>>> Did anyone ever come up with an acceptable solution for this?  After
>>>> three years, I'm getting tired of rebasing these patches onto every new
>>>> kernel.
>>>>
>>>> UUIDs or similar are NOT an option for multiple reasons:
>>>>
>>>> - We have two rootfs partitions for ping-pong updates, so simply
>>>>   referring to "the thing with ID foo" doesn't work.
>>>>
>>>> - Installing said updates needs direct access the device/partition,
>>>>   which may not even have a filesystem.
>>>>
>>>> - The u-boot environment is stored in an eMMC "boot" partition, and
>>>>   userspace needs to know where to find it.
>>>>
>>>> I'm sure I'm not the only one in a similar situation.
>>>>
>>>> Russel, feel free to shout abuse at me.  I don't care, but it makes you
>>>> look stupid.
>>>>
>>>
>>> Completely agree here - we need a dt solution that allows us to
>>> specify ordering.
>>
>> Nope, ordering would be a policy and does not describe hardware, thus it
>> shouldn't be in the DT. Use UUID or PARTUUID, they apply both to raw FS
>> (fsuuid) and to partitions (part uuid). Linux kernel can mount FS using
>> PARTUUID, to support UUID you need initramfs.
> 
> That doesn't address how to find eMMC boot partitions.

If you have a FS or partition table there, it does.
If you don't, I agree ... that's a problem.

> I don't care the slightest what the numbering is, as long as it is
> stable.  On some hardware, with an unpatched kernel, the mmc device
> numbering changes depending on whether or not an SD card is inserted on
> boot.  Getting rid of that behaviour is really all I want.

Agreed, that would be an improvement.

-- 
Best regards,
Marek Vasut