Received-SPF: pass (google.com: domain of linux-wireless+bounces-8816-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <e46407b3-3531-4935-a0a5-5132d5baa722@gmail.com>
Date: Tue, 11 Jun 2024 23:15:30 +0300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: ETIMEDOUT with rtl8xxxu
To: Martin Kaistra <martin.kaistra@linutronix.de>,
 Ping-Ke Shih <pkshih@realtek.com>
Cc: linux-wireless@vger.kernel.org
References: <ee08c815-9389-4277-be6d-197511636892@linutronix.de>
Content-Language: en-US
From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
In-Reply-To: <ee08c815-9389-4277-be6d-197511636892@linutronix.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11/06/2024 18:54, Martin Kaistra 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.
> 
> The strange thing now is, that even though it seems to be hardware dependent the vendor driver does not have this problem.
> 
> I tried to change the probe and start functions, so that they behaved exactly as their vendor driver equivalents, but so far I don't see any improvement.
> 
> I was hoping, that one of you maybe has an idea, what could be causing such an issue and how to avoid it.
> 
> Martin

Does it still die if you do a passive scan?

I wonder what vendor driver you are using? Is it loading the
same v4.0 firmware as rtl8xxxu?

Why reloading rtl8xxxu makes it work again? A USB reset?
Or something in the disconnect function?

To avoid the problem, obviously you have to make rtl8xxxu
even more like the vendor driver. :)