[PATCH 1/1] ARM: dts: orange-pi-zero-plus2: use fixed mmc indexes

[Maxime Ripard]

On Wed, Feb 03, 2021 at 05:36:58PM +0800, Chen-Yu Tsai wrote:
> On Wed, Feb 3, 2021 at 5:29 PM Maxime Ripard <maxime at cerno.tech> wrote:
> >
> > Hi,
> >
> > On Wed, Jan 27, 2021 at 08:46:20AM +0300, Sergey Matyukevich wrote:
> > > Driver sunxi-mmc has recently been switched to asynchronous probe.
> > > As a result, mmc indexes can be shuffled breaking existing setups
> > > where UUIDs are not used for boot devices. Pin mmc indexes to keep
> > > running the systems where fixed MMC or eMMC are specified,
> > > e.g. root=/dev/mmcblk0p2.
> > >
> > > Signed-off-by: Sergey Matyukevich <geomatsi at gmail.com>
> >
> > I'm not sure, really.
> >
> > That would change the indices once again, and you shouldn't really rely
> > on them anyway, there's never been any guarantee on the order of any
> > device.
> 
> I assume one reason people want stable MMC indices is for setting the
> root device. This could be done with UUID or PARTUUID.

PARTLABEL is also an option

> Another would be setting the LED trigger to some MMC device,
> preferably in the DT so it kicks in when the LED device is created.
> Though even that isn't guaranteed since the MMC could probe after the
> LED. :(
> 
> Currently I'm using some shell script to parse the root device then
> get the device name and program that as an LED trigger through sysfs.

Surely a udev / mdev rule can help there?

> > And whatever the outcome of that discussion, it definitely shouldn't be
> > done for a single board.
> 
> I believe this should be done at the SoC level so we would have consistent
> MMC indices across the board. However that seems to conflict with the order
> swap we currently have in U-boot to support eMMCs seamlessly.

I'm not sure we can do it at the SoC level anyway: if only the emmc is
enabled, we want it to be mmcblk0

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210203/5756cb84/attachment.sig>