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@xxxxxxxxxx> 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@xxxxxxxxx> > > > > 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:
signature.asc
Description: PGP signature
