Date:   Sat, 16 Mar 2019 13:33:58 +0100
From:   Marek Vasut <marex@...x.de>
To:     Måns Rullgård <mans@...sr.com>
Cc:     Tim Harvey <tharvey@...eworks.com>,
        Douglas Anderson <dianders@...omium.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Jaehoon Chung <jh80.chung@...sung.com>,
        shawn.lin@...k-chips.com, Adrian Hunter <adrian.hunter@...el.com>,
        stefan@...er.ch, Linux MMC List <linux-mmc@...r.kernel.org>,
        Brian Norris <computersforpeace@...il.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Jisheng Zhang <jszhang@...vell.com>,
        linux-rockchip@...ts.infradead.org,
        devicetree-spec@...r.kernel.org,
        Mark Rutland <mark.rutland@....com>,
        open list <linux-kernel@...r.kernel.org>,
        vbyravarasu@...dia.com, Lars-Peter Clausen <lars@...afoo.de>,
        Russell King - ARM Linux <linux@....linux.org.uk>,
        jonathanh@...dia.com, linux-arm-kernel@...ts.infradead.org,
        devicetree@...r.kernel.org, Pawel Moll <pawel.moll@....com>,
        Ian Campbell <ijc+devicetree@...lion.org.uk>,
        grundler@...omium.org, Kumar Gala <galak@...eaurora.org>,
        lporzio@...ron.com, Rob Herring <robh+dt@...nel.org>,
        "chaotian.j ing"@mediatek.com,
        Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        sudeep.holla@....com, zhonghui.fu@...ux.intel.com,
        kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering
 w/ device tree

On 3/16/19 1:22 PM, Måns Rullgård wrote:
> Marek Vasut <marex@...x.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@...sr.com> wrote:
>>>>
>>>> Douglas Anderson <dianders@...omium.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

Powered by blists - more mailing lists