linux-kernel - Re: [PATCH] mmc: sdhci-sprd: remove prefer asynchronous probe

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] [day] [month] [year] [list]

Message-ID: <CA+Da2qwDnNbinH3CHXHXHDHwB5PUaGMryQOeqoHnE=tcJ6QFqQ@mail.gmail.com>
Date:   Fri, 9 Dec 2022 14:37:33 +0800
From:   Wenchao Chen <wenchao.chen666@...il.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Wenchao Chen <wenchao.chen@...soc.com>, adrian.hunter@...el.com,
        orsonzhai@...il.com, baolin.wang@...ux.alibaba.com,
        zhang.lyra@...il.com, linux-mmc@...r.kernel.org,
        linux-kernel@...r.kernel.org, zhenxiong.lai@...soc.com,
        yuelin.tang@...soc.com, gengcixi@...il.com
Subject: Re: [PATCH] mmc: sdhci-sprd: remove prefer asynchronous probe

On Wed, Dec 7, 2022 at 8:50 PM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> On Fri, 2 Dec 2022 at 03:41, Wenchao Chen <wenchao.chen666@...il.com> wrote:
> >
> > On Thu, Dec 1, 2022 at 6:41 PM Ulf Hansson <ulf.hansson@...aro.org> wrote:
> > >
> > > On Thu, 1 Dec 2022 at 10:12, Wenchao Chen <wenchao.chen@...soc.com> wrote:
> > > >
> > > > The prefer asynchronous probe affects the order of device probes.
> > >
> > > Is there a problem with this? If so, can you elaborate on what kind of problems?
> > >
> >
> > Hi Uffe
> > dts:
> > sdio0: sdio@...00000 {
> > ...
> > bus-width = <4>;
> > no-sdio;
> > no-mmc;
> > ...
> > }; // SD Host(Device: SD CARD)
> >
> > sdio3: sdio@...00000 {
> > ...
> > bus-width = <8>;
> > non-removable;
> > no-sdio;
> > no-sd;
> > ...
> > }; // eMMC Host(Device: eMMC)
> >
> > According to the order of DTS: sdio0: sdio@...00000 is MMC0, sdio3:
> > sdio@...00000 is MMC1.
> > Log:
> > [    1.714617][   T11] mmc1: SDHCI controller on 71400000.sdio
> > [71400000.sdio] using ADMA 64-bit
> > [    1.715276][    T9] mmc0: SDHCI controller on 71100000.sdio
> > [71100000.sdio] using ADMA 64-bit
> > [    1.884525][   T75] mmc1: Host Software Queue enabled
> > [    1.890965][   T75] mmc1: new HS400 Enhanced strobe MMC card at address 0001
> >
> > But set prefer_asynchronous_probe, sometimes there will be sdio0:
> > sdio@...00000 is MMC1, sdio3: sdio@...00000 is MMC0.
> > Log:
> > [    1.619888][   T68] mmc0: SDHCI controller on 71400000.sdio
> > [71400000.sdio] using ADMA 64-bit
> > [    1.620534][    T9] mmc1: SDHCI controller on 71100000.sdio
> > [71100000.sdio] using ADMA 64-bit
> > [    1.792570][   T77] mmc0: Host Software Queue enabled
> > [    1.799532][   T77] mmc0: new HS400 Enhanced strobe MMC card at address 0001
>
> Neither the order of the nodes in DT or dropping
> PROBE_PREFER_ASYNCHRONOUS provides the guarantees that you suggest
> above. In fact, that has never been the case for eMMC/SD cards.
>
> >
> > We use emmc as rootfs (without ramfs or initfs), but with SD card
> > inserted and not inserted, the partition name of emmc is different, we
> > need to fix this partition name.
>
> If you can't use PARTUUID/UUID, which is certainly the preferred
> solution - you may also assign a fixed index mmcN to an MMC host
> controller and its corresponding mmcblk[n] devices, by defining an
> alias in the /aliases device tree node.
>

You're right.

        aliases {
...
               mmc0 = &sdio3;
               mmc1 = &sdio0;
...
        };

Thank you very much.

> [...]
>
> Kind regards
> Uffe