Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering
 w/ device tree
To:     =?UTF-8?B?TcOlbnMgUnVsbGfDpXJk?= <mans@mansr.com>
Cc:     Tim Harvey <tharvey@gateworks.com>,
        Douglas Anderson <dianders@chromium.org>,
        Ulf Hansson <ulf.hansson@linaro.org>,
        Jaehoon Chung <jh80.chung@samsung.com>,
        shawn.lin@rock-chips.com, Adrian Hunter <adrian.hunter@intel.com>,
        stefan@agner.ch, Linux MMC List <linux-mmc@vger.kernel.org>,
        Brian Norris <computersforpeace@gmail.com>,
        Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Heiko Stuebner <heiko@sntech.de>,
        Jisheng Zhang <jszhang@marvell.com>,
        linux-rockchip@lists.infradead.org,
        devicetree-spec@vger.kernel.org,
        Mark Rutland <mark.rutland@arm.com>,
        open list <linux-kernel@vger.kernel.org>,
        vbyravarasu@nvidia.com, Lars-Peter Clausen <lars@metafoo.de>,
        Russell King - ARM Linux <linux@arm.linux.org.uk>,
        jonathanh@nvidia.com, linux-arm-kernel@lists.infradead.org,
        devicetree@vger.kernel.org, Pawel Moll <pawel.moll@arm.com>,
        Ian Campbell <ijc+devicetree@hellion.org.uk>,
        grundler@chromium.org, Kumar Gala <galak@codeaurora.org>,
        lporzio@micron.com, Rob Herring <robh+dt@kernel.org>,
        "chaotian.j ing"@mediatek.com,
        Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
        sudeep.holla@arm.com, zhonghui.fu@linux.intel.com,
        kirill.shutemov@linux.intel.com
References: <1461951139-6109-1-git-send-email-dianders@chromium.org>
 <yw1x5zsx5wc7.fsf@mansr.com>
 <CAJ+vNU1PxK-B63Dc3AgzYb9POyxxoF-xPOWBEpxJ+3eVNK8xqw@mail.gmail.com>
 <d5310138-7fdd-973d-5210-3fc91c4686ee@denx.de> <yw1xftrn2em9.fsf@mansr.com>
From:   Marek Vasut <marex@denx.de>
Openpgp: preference=signencrypt
Autocrypt: addr=marex@denx.de; prefer-encrypt=mutual; keydata=
 mQINBFHmnxgBEACuQOC6Kaw/32MTeUJdFuDZ1FrbG76a0Ys/I02Kj9jXDmCCLvqq18Z4A1b0
 xbuMKGDy5WR77fqGV8zADUo6i1ATgCZeg+SRmQROF8r9K6n6digTznBySSLANhN3kXUMNRE1
 WEIBGCZJ5FF+Qq59AkAUTB8CiIzfEW98o7lUjeEume/78wR18+QW+2z6eYli2qNECceRINXT
 zS3oxRMr+ivqEUGKvMBC/WNLuvJoCGsfSQc2I+uGEU7MOdOCC6SsKdnPBGKYth5Ieb16bRS1
 b9M5BoEKTEzDCOWn92OxeHX6M2gLEMQobfM0RdIowMfWaUHdci2cLUTyL0T/P/gIpHMR2LhL
 8sdbNZufgv73s9PDgxTWMzypXimMJ7VZmVh9I2nQd2xm8+uE1rghqb90aEMFCTwUlrz4Qhjh
 vmczd2ScuuOMLzHEaaoOrMGbaWIEFcJvQgyHzJgMPgnG64eDq6uGyBEXRc3bBzv7B765Hcg8
 SSNqoUstjuQQlGp3y3Yj16l+PyZ3Ucy2swFYLVPTc35xFBk/uGEIhGncoFpOX29rxt9M8r5G
 hm7395m0GmDy50H/HN61/S8EPvM3HUjqBvX1EqU+vJXfwozxkKpIwcjx7h3W+PPS9TUb7r5v
 vHCqnrWRd/m6KWbCJsv0rsIU66o2qKYX5cIHV6u6Y7Zm7BtHfwARAQABtBtNYXJlayBWYXN1
 dCA8bWFyZXhAZGVueC5kZT6JAjgEEwECACIFAlHmnxgCGwMGCwkIBwMCBhUIAgkKCwQWAgMB
 Ah4BAheAAAoJEOtsLUEh5B0XLk0QAINOYFYB3v4KjXSFHYBQLlDblqhXvVtjyQHMiJsY1BMO
 mMrANUJQtpY3UkYquFspe2GBiFQbfW+mDlwFlSNpzaJ68qGEK+57I/MufsZKV6Ze9j7QeClu
 orYH+zfIBI7sn0HkY/MWN/Z270gRv2xSxDBP/8SPdB53EkImLZUFOo4/5eyuQ4t8HLgol02u
 2ncwXrnT036QC3SiNJDCJhwkpjvamPHghxr8hbIwkdOLZlYWfl0yzYzQohl8zBEwtBxl5cS4
 1TcrgBXsanQUMVNBpl0s8nQLKuHJNPOAhBnKstAe54yY3iWswYayHqqgqIQldcDqttHhdTJW
 mb9hTSf5p6fnZqcsfi3PUFwj5PJSN3aAbF8w42FwRvIOWbksFIWXpxYI3mq2TmX4GtlKdlF8
 xT+Q+Cbk538IBV4OQ5BapuYHs1C1ff9gVC0rfrCEloyteHafHwOv3ZuEGPlH89Rl4EjRvJxX
 8nE0sCiq6yUbpom8xRA5nFwA0bbTDwhH5RD/952bZraLpWcdJ6cWA2gefd2+2fy0268xyHmD
 m87B49BIaAsZ2kvEb/scCZ/CvPHjHLAjr+/GsdzOxwB68P41ZajujMDmbka00CyeAl88pgLX
 tTkPvAzuEDpRoJmg8zrQqrsmEKSdhFJhZ7d2MMKpCcVnInByXjM+1GEfSisTgWnluQINBFHm
 nxgBEAC8MpoO1s1AB0uRQGXlhYzkYvxkDGAe50/18ct2K6ORSv7HjCmZBjJX+2xTPSmML9ju
 3P0KrlnRdT8qCh+ozijffLjm5X9Fk+6mGQ56UQzivuPNlgyC3epF3Z58VPVQcIfE2/pdAxtZ
 zKc4P5t2yo5qk635huo0NvNg5mRhvfZ7mZpZuBahkHguR0Heh/tnGCa2v5P6uFbGX8+6rAA8
 EKxl5Tclf27PFZwbIWL1buS9RwgzsHj2TFnnEFIcWdMHyGy2GT8JMgY0VwxKebzGJg2RqfOL
 PaPjnvnXHAIYEknQp0TUtUiNxm0PBa4IQ30XhrB9D5QYdcw/DVvCzb9qyIlaQKEqHZm1fGU4
 iCsH3jV+5D4Lrn5JfXc/+A1NsLUq/NFIYhphbX4fGjR2QdZJrDnGVcxSlwP7CeRuxGELrASz
 m4G4Q0mYz7HdAlzBJHi8Ej4yC9l7PPlnxdUcAwheLxGwzMCf5vxw1C6Zi8PvKu/sY7Bha9XJ
 plvuLBi7QrkD8mZEzt+xC9nWRt7hL47+UvyduFe4qDMTPrW20ROxCykC36gj53YhqqLblioX
 2//vGLKj8x+LiLSTwjkLkrwOremhdTqr457511vOXyaZyOlWhFjN+4j9xwbbg1IWwMenRAb7
 Qwuipck6fN2o+PK9i6t6pWXrUDNI/VCMbimnuqPwAQARAQABiQIfBBgBAgAJBQJR5p8YAhsM
 AAoJEOtsLUEh5B0XMqAP/1HbrClefDZ/Lvvo89mgC56vWzEstmFo8EihqxVZvpkiCjJoCH53
 VCYeGl41p0y6K5gaLT28s9waVHBw+dhpwABba3neV/vyXv0wUtvkS3T0e4zruYFWw0lQoZi+
 8rtXTsuWN5t3u8avXsrdqD0CteTJdgZ7yBV8bBvK2ekqFMS/cLC+MoYlmUFn6Tcxmv0x8QZY
 ux6ts9YpUvx8QxMJt9vfwt1WIUEFKR3JQdrZmbPGqWJ3s+u/C+v9stC5qf2eYafRjzy05lEn
 B06W5D5Uc+FGEhuzq4G0eRLgivMoC0Eqz7HuwGcRAJYQILQ3Vzd4oHKPoUAtvlKqUwDmHodT
 HPmN73JMsvO3jLrSdl4k6o3CdlS/DI0Eto4fD0Wqh6d5q11u1TOM7+/LehWrOOoGVqRc6FFT
 ofck6h6rN/Urwkr1nWQ3kgO1cd/gevqy8Tevo/qkPYIf71BlypcXhKqn6IPjkq4QLiDPRjHM
 tgPc2T/X/ETe5eCuhxMytIYbt1fK2pDXPoIKbbDK4uEmg9USXZ+pYrac4PFo1d+6D6vmTjRZ
 GRRITOVpKgBndfPyqofxeKNKGdNf9FS/x89RlnDWXsQHm+0pXguSRG9XdB16ZFNgeo8SeZVr
 qc9uLfhyQp/zB6qEnuX1TToug7PuDgcNZdjN3vgTXyno2TFMxp/LKHqg
Message-ID: <1fcd4dad-1e00-67cc-ac5d-24640ae34340@denx.de>
Date:   Sat, 16 Mar 2019 13:33:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <yw1xftrn2em9.fsf@mansr.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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