lkml.org 
[lkml]   [2019]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree
From
Date
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

\
 
 \ /
  Last update: 2019-03-16 13:35    [W:0.125 / U:1.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site