Received-SPF: pass (google.com: domain of linux-wireless+bounces-8861-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <8581983e-714b-4173-9150-061f57516ab8@linutronix.de>
Date: Wed, 12 Jun 2024 14:20:33 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: ETIMEDOUT with rtl8xxxu
To: Ping-Ke Shih <pkshih@realtek.com>,
 Bitterblue Smith <rtl8821cerfe2@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
References: <ee08c815-9389-4277-be6d-197511636892@linutronix.de>
 <1385519564244924a1101770344544a0@realtek.com>
Content-Language: de-DE
From: Martin Kaistra <martin.kaistra@linutronix.de>
In-Reply-To: <1385519564244924a1101770344544a0@realtek.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Am 12.06.24 um 03:47 schrieb Ping-Ke Shih:
> Martin Kaistra <martin.kaistra@linutronix.de> wrote:
>> Hi Ping-Ke, hi Bitterblue,
>>
>> I have a problem with the rtl8xxxu driver and 8188f, but only on some boards.
>> More specifically, I can see that during the second channel switch (which
>> happens when I do "iw dev wlan0 scan"),  the rtl8xxxu_read32(0e08) returns -110
>> (ETIMEDOUT) and after that no reads or writes work anymore until I unload and
>> reload the driver.
> 
> If this symptom is 100% reproducible, I would add many rtl8xxxu_read32(0xe08)
> somewhere to bisect the cause resulting from writing IO or certain H2C commands.

Thanks to your suggestion, I found out that
1) the timeouts start occuring right after the first frame is sent (rtl8xxxu_tx)
2) the adress doesn't matter, rtl8xxxu_read8(0x100) also gets a timeout

I am now looking into the differences between vendor driver and rtl8xxxu for 
sending frames.

> 
> Example 1:
> 
> 	rtl8xxxu_write32(0x1234)	// original code
> 	rtl8xxxu_read32(0xe08)		// add this to see if problem encounters?
> 
> Example 2:
> 	rtl8xxxu_gen2_h2c_cmd()		// original code
> 	mdelay(50)					// add some delay to wait firmware complete the work
> 	rtl8xxxu_read32(0xe08)		// add this to see if problem encounters?
> 
> The address of 0xe08 is not always on, so you should read it after power-on.
> 
> 
> 
>