git: 043d6a24b290 - main - rtwn: add workaround sleep in r92e_set_chan()

The branch main has been updated by adrian:

URL: https://cgit.FreeBSD.org/src/commit/?id=043d6a24b29030989fdf2b79c5ff90391f859225

commit 043d6a24b29030989fdf2b79c5ff90391f859225
Author:     Adrian Chadd <adrian@FreeBSD.org>
AuthorDate: 2025-01-19 20:16:55 +0000
Commit:     Adrian Chadd <adrian@FreeBSD.org>
CommitDate: 2025-01-22 21:46:57 +0000

    rtwn: add workaround sleep in r92e_set_chan()
    
    It /looks/ like there's some weirdness in initial frame send after
    the chip programming / channel change.  Linux rtl8xxxu has no sleeps
    here, instead it just retries the auth frame a few times.
    
    My guess is there's some sequencing going on here between finishing
    the programming, doing a calibration run and then sending the initial
    frame.
    
    Instead of doing sleeps on every write during the RF channel change,
    this 10ms sleep at the end is enough to reliably associate in my
    test environment (12-core intel laptop, USB-3 port.)  It's not
    required for an earlier 2-core haswell laptop w/ USB-3.
    
    See the PR for more information.
    
    PR:             kern/247528
    Differential Revision:  https://reviews.freebsd.org/D48517
---
 sys/dev/rtwn/rtl8192e/r92e_chan.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/sys/dev/rtwn/rtl8192e/r92e_chan.c b/sys/dev/rtwn/rtl8192e/r92e_chan.c
index 4c7121a80c89..4cf17433d257 100644
--- a/sys/dev/rtwn/rtl8192e/r92e_chan.c
+++ b/sys/dev/rtwn/rtl8192e/r92e_chan.c
@@ -252,4 +252,28 @@ r92e_set_chan(struct rtwn_softc *sc, struct ieee80211_channel *c)
 
 	/* Set Tx power for this new channel. */
 	r92e_set_txpower(sc, c);
+
+	/*
+	 * Work around some timing issues with RTL8192EU on faster
+	 * CPUs / USB-3 ports by sleeping for 10ms.
+	 *
+	 * Without this delay the initial frame send during authentication
+	 * doesn't occur.
+	 *
+	 * My (adrian) guess is that there's a race condition between
+	 * everything being programmed into the hardware and the first
+	 * send.  Notably, TXPAUSE isn't 0x0 after rf init,
+	 * which the rtl8xxxu driver has a commit to address (c6015bf3ff1ff)
+	 * - wifi: rtl8xxxu: fixing transmission failure for rtl8192eu
+	 *
+	 * Although it's hard to do due to locking constraints, reading
+	 * TXPAUSE during scan / association shows it's non-zero, which
+	 * needs to be looked at in more depth.
+	 *
+	 * Linux doesn't have a delay here, however it does try multiple
+	 * times to send an authentication frame.
+	 *
+	 * See PR/247528 for more info.
+	 */
+	rtwn_delay(sc, 10000);
 }