| Message ID | 20210127054620.510912-1-geomatsi@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/1] ARM: dts: orange-pi-zero-plus2: use fixed mmc indexes | expand |
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. And whatever the outcome of that discussion, it definitely shouldn't be done for a single board. Maxime
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. 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. > 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. Regards ChenYu
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
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts index de19e68eb84e..c4854d3ba524 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts @@ -13,6 +13,9 @@ / { aliases { serial0 = &uart0; + mmc0 = &mmc0; + mmc1 = &mmc1; + mmc2 = &mmc2; }; chosen {
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> --- .../arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts | 3 +++ 1 file changed, 3 insertions(+)