On Wed, 29 Jul 2020 at 10:43, Matthias Schiffer
[off-list ref] wrote:

On Tue, 2020-07-07 at 16:14 +0200, Ulf Hansson wrote:

quoted

On Thu, 11 Jun 2020 at 13:20, Matthias Schiffer
[off-list ref] wrote:

quoted

On Wed, 2020-06-10 at 16:52 +0200, Ulf Hansson wrote:

quoted

On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer
[off-list ref] wrote:

quoted

Hello all,

there have been numerous attempts to make the numbering of
mmcblk
devices consistent, mostly by using aliases from the DTS ([1],
[2],
[3]), but all have been (rightfully) rejected. Unless I have
overlooked
a more recent development, no attempts for a different solution
were
made.

According to aliases attempts, I think those have failed, mainly
because of two reasons.

1. Arguments stating that LABELs/UUIDs are variable alternatives.
This
isn't the case, which I think was also concluded from the several
earlier discussions.
2. Patches that tried adding support for mmc aliases, were not
correctly coded. More precisely, what needs to be addressed is
that
the mmc core also preserves the same ids to be set for the host
class
as the block device, mmc[n] must correspond to mmcblk[n].

quoted

As far as I can tell, the core of the issue seems to be the
following:

The existing solutions like LABELs and UUIDs are viable
alternatives in
many cases, but in particular on embedded systems, this is not
quite
sufficient: In addition to the problem that more knowledge
about
the
system to boot is required in the bootloader, this approach
fails
completely when the same firmware image exists on multiple
devices,
for
example on an eMMC and an SD card - not an entirely uncommon
situation
during the development of embedded systems.

With udev, I can refer to a specific partition using a path
like
/dev/disk/by-path/platform-2194000.usdhc-part2. In [4] it was
proposed
to add a way to refer to a device path/phandle from the kernel
command
line. Has there been any progress on this proposal?

Lots of time during the years I have been approached, both
publicly
and offlist, about whether it would be possible to add support
for
"consistent" mmcblk devices. To me, I am fine with the aliases
approach, as long as it gets implemented correctly.

It seems the principal technical problem is the one described here:

https://www.spinics.net/lists/linux-mmc/msg26602.html

I don't see any way to solve this completely, as there seem to be
two
fundamentally conflicting requirements:

1) If a mounted SD card is replaced, it must be assigned a new
/dev/mmcblkN
2) /dev/mmcblkN should always match the configured alias IDs

What is the reason we need 1) - is it possible to have multiple
eMMCs
or SD cards on a single bus, with detection at runtime?

Yes. The mmc_bus_type holds all cards - all discovered at runtime.

quoted

Otherwise I'd
expect this to be handled like other drives with removable media
(CD,
floppy), with static device assignment.

If we can't give up on 1) for some reason, we'll have to accept
that we
can't guarantee 2) unconditionally. As far as I can tell, the
patches
provided by Sascha and others did that in a reasonable way: The
aliases
would work in most cases - in particular for the first assignment
on
boot, which is required to find the correct rootfs.

Well, if we would pre-parse the DTB to look for all "mmc block
aliases" and keep a mark of those ids as being reserved, then we
should be able to cope with both 1) and 2).

Hello Ulf,

it seems to me like Sascha's patches from 2014 do precisely that:

https://www.spinics.net/lists/linux-mmc/msg26587.html
https://www.spinics.net/lists/linux-mmc/msg26588.html

I haven't looked into porting this to a modern kernel yet, but do you
think that the approach is sound?

Yes, something along those lines.

Kind regards
Uffe