Received-SPF: pass (google.com: domain of linux-wireless+bounces-6146-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: Kalle Valo <kvalo@kernel.org>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>,  Larry Finger
 <Larry.Finger@gmail.com>,  Johannes Berg <johannes@sipsolutions.net>,
  "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [RFC] rtw88: Fix startup problems for SDIO wifi plus UART
 Bluetooth
References: <4umro86wvv84.MjDfYvt4P5uZryt8boBK8Q2@1EHFQ.trk.elasticemail.com>
	<5af71338f3904aac9d2c237637c851e7@realtek.com>
	<287e9d4e-316a-4579-961e-58e75abea534@lwfinger.net>
Date: Thu, 11 Apr 2024 10:08:47 +0300
In-Reply-To: <287e9d4e-316a-4579-961e-58e75abea534@lwfinger.net> (Larry
	Finger's message of "Wed, 10 Apr 2024 21:47:58 -0500")
Message-ID: <87o7agjs00.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

(dropping stable list from cc)

Larry Finger <Larry.Finger@lwfinger.net> writes:

> On 4/10/24 9:13 PM, Ping-Ke Shih wrote:
>> Larry Finger <Larry.Finger@gmail.com> 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

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches