On 4/11/24 2:08 AM, Kalle Valo wrote:
(dropping stable list from cc)
Larry Finger <Larry.Finger@xxxxxxxxxxxx> writes:
On 4/10/24 9:13 PM, Ping-Ke Shih wrote:
Larry Finger <Larry.Finger@xxxxxxxxx> wrote:
As discussed in the links below, the SDIO part of RTW8821CS fails to
start correctly if such startup happens while the UART portion of
the chip is initializing.
I checked with SDIO team internally, but they didn't meet this case,
so we may
take this workaround.
SDIO team wonder if something other than BT cause this failure, and
after
system boots everything will be well. Could you boot the system without WiFi/BT
drivers, but insmod drivers manually after booting?
I sent the request to the user with the problem. I do not have any SDIO devices.
---
drivers/net/wireless/realtek/rtw88/sdio.c | 28 +++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/sdio.c b/drivers/net/wireless/realtek/rtw88/sdio.c
index 0cae5746f540..eec0ad85be72 100644
--- a/drivers/net/wireless/realtek/rtw88/sdio.c
+++ b/drivers/net/wireless/realtek/rtw88/sdio.c
@@ -1325,6 +1325,34 @@ int rtw_sdio_probe(struct sdio_func *sdio_func,
[...]
+ mdelay(500);
Will it better to use sleep function?
My thoughts were that a sleep function would tie up a CPU, whereas the
delay would not.
It's actually the opposite, msleep() allows other processes to run.
"In general, use of mdelay is discouraged and code should be refactored
to allow for the use of msleep."
https://docs.kernel.org/timers/timers-howto.html
Kalle and Ping-ke,
Sorry that I got that wrong. I have become just another confused old man. :)
The OP at GitHub has tested kernels where he blacklisted the BT drivers. The
wifi failed every time (3 tries with a delay and 3 times without). When he built
a kernel with BT built-in rather than as a module, it worked (again 3 tries).
There definitely is an interaction between the BT initialization and the wifi
setup. If the BT part is not started and has not completed the UART
initialization, SDIO wifi does not initialize correctly.
When it fails, unloading the wifi driver and reloading it restores wifi.
I originally wondered if there was a power problem when both were simultaneously
started, but I see that is not the case. To reiterate, the BT must start first
and complete UART initialization before the wifi starts initializing. It seems
to me that a suitable msleep() at the start of the SDIO probe routine seems to
be a viable workaround even though it is not aesthetically pleasing. A sleep of
150 ms is too short, but 500 seems to work reliably.
Perhaps the SDIO experts at Realtek may be able to offer a more satisfying
explanation. The OP at GitHub and I will try to answer any questions they might
have. Note that I do not have the hardware, but my contact at GitHub is
knowledgeable, and seems eager to help.
Larry
