linux-kernel - Re: mmc: core: Disable card detect during shutdown

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: <CAPDyKFq23_vCunapQ=OHFFGXs5a8_cr8w7hBUP=HQ5f2zaTBUg@mail.gmail.com>
Date:   Thu, 2 Mar 2023 11:36:58 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Tim Harvey <tharvey@...eworks.com>,
        Robert Richter <rric@...nel.org>
Cc:     "H. Nikolaus Schaller" <hns@...delico.com>,
        Tony Lindgren <tony@...mide.com>,
        linux-omap <linux-omap@...r.kernel.org>,
        linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux MMC List <linux-mmc@...r.kernel.org>,
        Jan Glauber <jan.glauber@...il.com>
Subject: Re: mmc: core: Disable card detect during shutdown

+ Robert

On Thu, 2 Mar 2023 at 00:32, Tim Harvey <tharvey@...eworks.com> wrote:
>
> Greetings,
>
> I've encountered a hang on shutdown on octeontx (CN8030 SoC, THUNDERX
> architecture) that I bisected to commit 66c915d09b94 ("mmc: core:
> Disable card detect during shutdown").
>
> It looks like the OMP5 Pyra ran into this as well related to a
> malfunctioning driver [1]
>
> In the case of MMC_CAVIUM_THUNDERX the host controller supports
> multiple slots each having their own CMD signal but shared clk/data
> via the following dt:
>
> mmc@1,4 {
>         compatible = "cavium,thunder-8890-mmc";
>         reg = <0xc00 0x00 0x00 0x00 0x00>;
>         #address-cells = <0x01>;
>         #size-cells = <0x00>;
>         clocks = <0x0b>;
>
>         /* eMMC */
>         mmc-slot@0 {
>                 compatible = "mmc-slot";
>                 reg = <0>;
>                 vmmc-supply = <&mmc_supply_3v3>;
>                 max-frequency = <35000000>;
>                 no-1-8-v;
>                 bus-width = <8>;
>                 no-sdio;
>                 no-sd;
>                 mmc-ddr-3_3v;
>                 cap-mmc-highspeed;
>         };
>
>         /* microSD */
>         mmc-slot@1 {
>                 compatible = "mmc-slot";
>                 reg = <1>;
>                 vmmc-supply = <&mmc_supply_3v3>;
>                 max-frequency = <35000000>;
>                 no-1-8-v;
>                 broken-cd;
>                 bus-width = <4>;
>                 cap-sd-highspeed;
>         };
> };
>
> mmc_add_host is only called once for mmc0 and I can't see any printk

That looks wrong. There needs to be one mmc host registered per slot,
otherwise things will, for sure, not work.

I suggest you have a closer look to see what goes on in thunder_mmc_probe().

> debugging added to __mmc_stop_host (maybe because serial/console has
> been disabled by that point?).

The serial console should work fine at this point, at least on those
systems that I have tested this code with.

Perhaps you added the debug print too late in the function, if the
calls to disable_irq() or cancel_delayed_work_sync() are hanging?

>
> It appears that what causes this hang is the 'broken-cd' which enables
> the detect change polling on mmc1. I have the ability to flip the CMD
> signal routing thus making mmc0 the microSD and mmc1 the eMMC and when
> I do that there isn't an issue so I think what happens is in the case
> where mmc polling is enabled on mmc1 but not mmc0 (as above) the
> polling causes a hang after __mmc_stop_host() is called for mmc0.

The code in __mmc_stop_host() has been tested for both polling and
gpio card detections. That said, it looks to me that there is
something weird going on in the cavium mmc driver.

What makes this even tricker, is that it's uncommon and not
recommended to use more than one mmc slot per host instance.

>
> Any ideas?

I hope the above thoughts can point you in a direction to narrow down
this problem.

>
> Best Regards,
>
> Tim
>
> [1] https://lore.kernel.org/all/55A0788B-03E8-457E-B093-40FD93F1B9F3@goldelico.com/

Kind regards
Uffe