On 06/03/2023 11:24, Marc Gonzalez wrote:
> # cat /sys/bus/sdio/devices/mmc2:0001:1/uevent
> OF_NAME=wifi
> OF_FULLNAME=/soc/sd@ffe03000/wifi@1
> OF_COMPATIBLE_0=brcm,bcm4329-fmac
> OF_COMPATIBLE_N=1
> SDIO_CLASS=00
> SDIO_ID=02D0:AAE7
> SDIO_REVISION=0.0
> MODALIAS=sdio:c00v02D0dAAE7
>
> NB: 0xaae7 = 43751
I have run into another issue.
The WiFi device (and the mmc2 bus it sits on) don't show up at all
in the kernel log *unless* I add lots of debug output, such as with
#define DEBUG in drivers/base/dd.c
I think this points to some kind of race condition?
Neil suggested that maybe the host probes the mmc2 bus "too soon",
when the WiFi device is still powering up, which makes the entire
probe fail.
This patch appears to solve the symptom:
diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index 6e5ea0213b477..999b3843c0d0b 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -1400,7 +1400,7 @@ static struct platform_driver meson_mmc_driver = {
.remove = meson_mmc_remove,
.driver = {
.name = DRIVER_NAME,
- .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ .probe_type = PROBE_FORCE_SYNCHRONOUS,
.of_match_table = meson_mmc_of_match,
},
};
But this might just be delaying the probe enough for the device
to become ready?
Ideas/Suggestions?
Regards
