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

From: Maxime Ripard <maxime@cerno.tech>
To: Chen-Yu Tsai <wens@csie.org>
Cc: devicetree <devicetree@vger.kernel.org>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Sergey Matyukevich <geomatsi@gmail.com>
Subject: Re: [PATCH 1/1] ARM: dts: orange-pi-zero-plus2: use fixed mmc indexes
Date: Wed, 3 Feb 2021 11:00:19 +0100	[thread overview]
Message-ID: <20210203100019.sdlb6rxfoxl45b2h@gilmour> (raw)
In-Reply-To: <CAGb2v66cskANPS7Zc_atCv9WYRq_aAEUi6Dd6LBrDPODOJ_ueQ@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 1854 bytes --]

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@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@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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel