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
debugging added to __mmc_stop_host (maybe because serial/console has
been disabled by that point?).
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.
Any ideas?
Best Regards,
Tim
[1] https://lore.kernel.org/all/55A0788B-03E8-457E-B093-40FD93F1B9F3@xxxxxxxxxxxxx/
