linux-kernel - Re: [PATCH] arm64: dts: rockchip: Assign a fixed index to mmc devices on rk3399-roc-pc boards.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <10029979.JCShpOL5JR@diego>
Date:   Wed, 04 Nov 2020 16:54:33 +0100
From:   Heiko Stübner <heiko@...ech.de>
To:     Doug Anderson <dianders@...omium.org>
Cc:     "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Markus Reichl <m.reichl@...etechno.de>,
        Rob Herring <robh@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm64: dts: rockchip: Assign a fixed index to mmc devices on rk3399-roc-pc boards.

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 <heiko@...ech.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.reichl@...etechno.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?


> 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 ;-) .


Heiko