Adrian Chadd 043d6a24b2 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		2025-01-22 13:46:57 -08:00
..
usb	rtwn: create a new HAL routine for enabling STA mode beacon processing	2024-12-20 12:40:19 -08:00
r92e.h	rtwn: try enforcing net80211 regulatory / txpower limits for 11n chips	2024-12-18 15:46:15 -08:00
r92e_chan.c	rtwn: add workaround sleep in r92e_set_chan()	2025-01-22 13:46:57 -08:00
r92e_fw.c	sys: Remove $FreeBSD$: one-line .c pattern	2023-08-16 11:54:36 -06:00
r92e_init.c	rtwn: fix RTL8192EU power-down / power-up hanging	2025-01-22 13:46:57 -08:00
r92e_led.c	sys: Remove $FreeBSD$: one-line .c pattern	2023-08-16 11:54:36 -06:00
r92e_priv.h
r92e_reg.h
r92e_rf.c	rtwn: bring the RTL8192EU RF read/write routines in line with rtl8xxxu	2025-01-22 13:46:57 -08:00
r92e_rom.c	sys: Remove $FreeBSD$: one-line .c pattern	2023-08-16 11:54:36 -06:00
r92e_rom_defs.h
r92e_rom_image.h
r92e_rx.c	sys: Remove $FreeBSD$: one-line .c pattern	2023-08-16 11:54:36 -06:00
r92e_var.h