On Wed, Nov 04, 2020 at 02:44:10PM +0100, Marek Szyprowski wrote: > On 04.11.2020 14:13, Marek Szyprowski wrote: > > On 04.11.2020 14:06, Markus Reichl wrote: > >> Am 04.11.20 um 13:25 schrieb Marek Szyprowski: > >>> On 04.11.2020 11:25, Markus Reichl wrote: > >>>> Recently introduced async probe on mmc devices can shuffle block IDs. > >>>> Pin them to fixed values to ease booting in evironments where UUIDs > >>>> ar not practical. > >>>> Use newly introduced aliases for mmcblk devices from [1]. > >>>> > >>>> [1] > >>>> https://patchwork.kernel.org/patch/11747669/ > >>>> > >>>> Signed-off-by: Markus Reichl <m.reichl@xxxxxxxxxxxxx> > >>>> --- > >>>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 +++++ > >>>> 1 file changed, 5 insertions(+) > >>>> > >>>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi > >>>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi > >>>> index a5c1ce1e396c..aa10d5bc7e1c 100644 > >>>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi > >>>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi > >>>> @@ -13,6 +13,11 @@ > >>>> #include "exynos-mfc-reserved-memory.dtsi" > >>>> / { > >>>> + aliases { > >>>> + mmc0 = &sdhci_2; > >>>> + mmc1 = &mshc_0; > >>> Like in the OdroidXU3-family patch, I would use 0 for the eMMC (mshc_0) > >>> and 2 for the SD-card (sdhci_2). > >> How to deal then with sdhci_0 (from exynos4.dtsi) vc. mshc_0 (from > >> exynos4412.dts)? > > sdhci_0 and mshc_0 both operate on the same physical MMC0 bus, so this > > is not an issue. They cannot be used simultaneously. The latter is just > > faster, the first one has been left there mainly for the software > > compatibility. > > I've thought a bit more on this and I would simply prefer to add generic > MMC aliases to the top-level Exynos dtsi files (3250, 4210, 4412, 5250, > 5410, 5420) to keep Linux logical MMC bus numbers in sync with the HW > bus numbers on all boards. I like this approach - I don't see much benefit of having different numbering between boards of the same SoC. Let's match old U-Boot behavior (I assume that people switch to PARTUUID around the v4.0 mixup, so they should not be affected). Best regards, Krzysztof