On Wed, Nov 4, 2020 at 11:55 PM Heiko Stübner <he...@sntech.de> wrote: > > Am Mittwoch, 4. November 2020, 16:42:01 CET schrieb Doug Anderson: > > Hi, > > > > On Wed, Nov 4, 2020 at 2:51 AM Heiko Stübner <he...@sntech.de> wrote: > > > > > > Hi Markus, > > > > > > Am Mittwoch, 4. November 2020, 10:49:45 CET schrieb Markus Reichl: > > > > Recently introduced async probe on mmc devices can shuffle block IDs. > > > > Pin them to fixed values to ease booting in evironments where UUIDs > > > > are not practical. Use newly introduced aliases for mmcblk devices from > > > > [1]. > > > > > > > > [1] > > > > https://patchwork.kernel.org/patch/11747669/ > > > > > > > > Signed-off-by: Markus Reichl <m.rei...@fivetechno.de> > > > > --- > > > > arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi | 5 +++++ > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi > > > > b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi > > > > index e7a459fa4322..bc9482b59428 100644 > > > > --- a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi > > > > +++ b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi > > > > @@ -13,6 +13,11 @@ / { > > > > model = "Firefly ROC-RK3399-PC Board"; > > > > compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399"; > > > > > > > > + aliases { > > > > + mmc0 = &sdmmc; > > > > + mmc1 = &sdhci; > > > > + }; > > > > + > > > > > > Any reason for this odering? > > > > > > I.e. some previous incarnations had it ordered as (emmc, mmc, sdio). > > > This is also true for the ChromeOS out-of-tree usage of those, the > > > rk3399 dts in the chromeos-4.4 tree also orders this as sdhci, sdmmc, > > > sdio. > > > > > > And I guess a further question would be when we're doing arbitary > > > orderings > > > anyway, why is this not in rk3399.dtsi ;-) ? > > > > Though I personally like the idea of eMMC, which is typically > > built-in, as being the "0" number, I'm personally happy with any > > numbering scheme that's consistent. Ordering them by base address is > > OK w/ me and seems less controversial. That seems like it could go in > > rk3399.dtsi and then if a particular board wanted a different order > > they could override it in their board file. > > Yep that sounds sensible and ordering by base address at least is one > "simple" type of order without too much explanation needed. > > So I guess we'd get a sdio + sdmmc + sdhci ordering > > > @Markus: if nobody else complains, can you do a "simple" rk3399.dtsi > change with that please?
Please also fix the LED triggers. :) > > The downside of putting > > in rk3399 is that boards that don't have all SD/MMC interfaces enabled > > would definitely get a new number compared to old kernels, but > > hopefully this is the last time? > > With that new asynchronous mmc-probe-thingy in 5.10 that "caused" this, > it sounds like everything gets a new number anyway ;-) . Yup.
