Repository navigation
Enable CONFIG_RTW89_8852AU (RTL8852AU/8832AU USB Wi-Fi 6) #7646
Description
Activity
You appear to be running a 6.12 kernel, and we're currently shipping 6.18, but (as you said) the driver only appeared in 6.19. There are four commits that make up the driver in 6.19:
0029ccab53acc wifi: rtw89: Add rtw8852au.c a2f1fc9ab6fb0 wifi: rtw89: 8852au: add support for TP TX30U Plus 292c0bc8acb68 wifi: rtw89: Add support for D-Link VR Air Bridge (DWA-F18) 623c177323ec1 wifi: rtw89: Enable the new rtw89_8852au moduleI'm prepared to backport them to 6.18 - they apply cleanly - and add the extra config setting. As that what you had in mind?
Hi @pelwell, Thanks for the quick reply! That is exactly what I have in mind! I'll upgrade to trixie / 6.18 kernel soon and that's why.
The linked issue #7647 is interesting: I think, we also need commit 80119a77e5b0 on top of the commits mentioned by you if we want to use the adapter in access point mode - agree? That seems to be handled via PR #7648 though.
I spoke too soon - although the commits apply, they don't build as is on 6.18 due to other changes. I'll see how painful its actually going to be, but I'm not promising anything.
Reacted by ChrisNo worries! I think the drivers would be a cool addition to the current kernel but it's not like we're talking about a critical bug here.
Amazing! I never expected this to happen that fast.
I'll not try to run my bookworm with the 6.18 kernel but install a fresh trixie first - and then the risk of breaking something is irrelevant anyways.
Reacted by Phil ElwellDid you manage to try this yet?
I tried but my system wouldn't start with the new kernel from
pulls/7649. I need to dig a bit deeper, why that is and I didn't have the time for that yet.Do you perhaps have a setup that relies on an initramfs, e.g. to use a root file system of a format or on a medium that requires a loadable module? You can test by setting
auto_initramfs=0in config.txt without any other changes and seeing if it still boots.I already tried
auto_initramfs=0with no success! I'll probably have the time to have a closer look during the next days.@pelwell I managed to test the new kernel, the driver is included:
chris@raspberrypi:~ $ uname -a Linux raspberrypi 6.18.53-v8+ #1 SMP PREEMPT Fri Sep 25 09:45:23 UTC 2026 aarch64 GNU/Linux chris@raspberrypi:~ $ modinfo -n rtw89_8852au /lib/modules/6.18.53-v8+/kernel/drivers/net/wireless/realtek/rtw89/rtw89_8852au.ko.xzHowever, the device fails to power on:
[ 9.723186] rtw89_8852au 1-1.1:1.0: loaded firmware rtw89/rtw8852a_fw.bin [ 9.724064] rtw89_8852au 1-1.1:1.0: MAC has already powered on [ 9.725566] rtw89_8852au 1-1.1:1.0: usb write8 0x5 fail ret=-71 value=0x4 attempt=0 [ 9.725838] rtw89_8852au 1-1.1:1.0: usb write8 0x5 fail ret=-71 value=0x4 attempt=1 [ 9.726101] rtw89_8852au 1-1.1:1.0: usb write8 0x5 fail ret=-71 value=0x4 attempt=2 [ 9.726354] rtw89_8852au 1-1.1:1.0: usb write8 0x5 fail ret=-71 value=0x4 attempt=3 [ 9.726605] rtw89_8852au 1-1.1:1.0: usb write8 0x5 fail ret=-71 value=0x4 attempt=4 [ 11.726791] rtw89_8852au 1-1.1:1.0: [ERR] Polling timeout [ 11.726803] rtw89_8852au 1-1.1:1.0: [ERR] addr: 6, 6 [ 11.726809] rtw89_8852au 1-1.1:1.0: [ERR] val: 0, 2 [ 11.726816] rtw89_8852au 1-1.1:1.0: failed to power on [ 11.726820] rtw89_8852au 1-1.1:1.0: failed to setup chip information [ 11.727315] rtw89_8852au 1-1.1:1.0: probe with driver rtw89_8852au failed with error -16 [ 11.727428] usbcore: registered new interface driver rtw89_8852auI asked Claude to analyze the issue, here is the result (I cannot at all judge on it):
The failing write is the PCIe-only step {0x0005, …, PWR_INTF_MSK_PCIE, PWR_CMD_WRITE, BIT(2), BIT(2)} in rtw8852a_pwroff: rtw89_mac_pwr_seq() in 6.18 hardcodes PWR_INTF_MSK_PCIE, fixed upstream by 233542f ("Use the correct power sequences for USB/SDIO"). The 8852A chip-side USB enablement that precedes 0029cca upstream is missing from the PR:
- 32e0381 wifi: rtw89: Fix rtw89_mac_dmac_func_pre_en_ax() for USB/SDIO
- 233542f wifi: rtw89: Use the correct power sequences for USB/SDIO
- 0eea5e0 wifi: rtw89: Add rtw8852a_dle_mem_usb
- c19b106 wifi: rtw89: Add rtw8852a_hfc_param_ini_usb
- 1dfd11e wifi: rtw89: 8852a: Accept USB devices and load their MAC address
Without the other four, probe would fail next at [ERR]get_dle_mem_cfg (dle_mem[USB] is NULL for 8852A) and then in rtw8852a_read_efuse() (-ENOTSUPP for USB).
Edit: Using
auto_initramfs=0on a clean installation during the first boot (instead of changing it from 1 to 0 on a system that had already booted with 1) solved my issue of the system not starting up.Edit 2: Any chance you also cherry-pick [80119a7] from #7647 into this PR if you decide to go on this this topic?
Great, thanks!
rtw89_8852au 1-1.1:1.0: loaded firmware rtw89/rtw8852a_fw.bin rtw89_8852au 1-1.1:1.0: MAC has already powered on rtw89_8852au 1-1.1:1.0: Firmware version 0.13.36.2 (52acc807), cmd version 0, type 1 rtw89_8852au 1-1.1:1.0: Firmware version 0.13.36.2 (52acc807), cmd version 0, type 3 rtw89_8852au 1-1.1:1.0: chip rfe_type is 1I tested bb360b9 (6.18.54-v8+) in USB 2 mode, since there's no USB 3 mode switch. Power on, probe, scanning works!
My main use-case (access point) dosen't work though:
- WPA2-PSK: the client associates and EAPOL 1/4 is sent four times (all acked), but 2/4 never arrives, so the handshake times out (iw event):
wlan1: new station 60:57:18:6f:bb:5c
wlan1 (phy #2): ctrl. port TX status (cookie 5): acked
wlan1 (phy #2): ctrl. port TX status (cookie 6): acked
wlan1 (phy #2): ctrl. port TX status (cookie 7): acked
wlan1 (phy #2): ctrl. port TX status (cookie 8): acked
wlan1: del station 60:57:18:6f:bb:5c - Open: association works and DHCPDISCOVER arrives, but the DHCPOFFER never reaches the client:
wpa_supplicant: wlan1: AP-STA-CONNECTED 60:57:18:6f:bb:5c
dnsmasq-dhcp: DHCPDISCOVER(wlan1) 60:57:18:6f:bb:5c
dnsmasq-dhcp: DHCPOFFER(wlan1) 192.168.77.245 60:57:18:6f:bb:5c
dnsmasq-dhcp: DHCPDISCOVER(wlan1) 60:57:18:6f:bb:5c
dnsmasq-dhcp: DHCPOFFER(wlan1) 192.168.77.245 60:57:18:6f:bb:5c - The firmware also hangs, and once the chip reset itself back into mass-storage mode:
rtw89_8852au 1-1.1:1.0: Polling beacon packet empty fail
rtw89_8852au 1-1.1:1.0: c2h reg timeout
usb 1-1.1: USB disconnect, device number 5
usb 1-1.1: New USB device found, idVendor=0bda, idProduct=1a2b, bcdDevice= 0.00
I then tried the stock 6.18.50+rpt-rpi-v8 kernel and the out-of-tree morrownr/rtw89 driver (forced into USB2 mode) and it works. Something from morrownr/rtw89 still seems to be missing from the backport. I don't want to guess here.
Side note: Station mode fails with both drivers while the Pi's onboard radio connects fine.Not sure if it is worth going on with investigations here. Would a trial build of rpi-7.1.y with
CONFIG_RTW89_8852AU=mbe feasible, to see whether current upstream behaves like the out-of-tree driver?- WPA2-PSK: the client associates and EAPOL 1/4 is sent four times (all acked), but 2/4 never arrives, so the handshake times out (iw event):
chris@raspberrypi:~ $ uname -r 7.3.0-rc5-v8+ chris@raspberrypi:~ $ cat /boot/firmware/.firmware_revision 90cbe95ebde55993e4c6604c56625a1506725ed8-> Works like a charm, access point as well as station mode, USB2 and USB3 port. Defo worth enabling CONFIG_RTW89_8852AU=m in the 7.x defconfigs.
Regarding 6.18.y backport: We're missing driver changes from somewhere between v6.19 and v7.3. I'm right now spending some tokens to identify candidates.
(Edit @pelwell ) Result (Opus 5.5):
Likely cause: the backport is missing upstream commit 89acd6c ("wifi: rtw89: Add rtw89_core_get_ch_dma_v2()", v6.19-rc1). It's the first patch of Bitterblue's 8852CU/8852AU series. All other 8852A-related patches of that series are already in this PR.
Without it, 8852AU on USB uses the PCIe qsel→DMA channel mapping: VO→ACH3, BK→ACH1, B0_HI→CH9, B1_HI→CH11. But rtw8852a_hfc_chcfg_usb gives those channels a quota of 0, and rtw8852a_usb_info.bulkout_id has no endpoint for ACH1/ACH3. So EAPOL frames (VO) and AP broadcast/multicast (HIQ) get stuck. That matches what we saw: EAPOL 2/4 never arrives, DHCPOFFER is not delivered, plus flush and c2h timeouts.
It applies cleanly on top of bb360b9. If station mode still fails afterwards, the 6.19 USB TX-report series (c33c6a1, cc7070e, 816e849, d5da3d9, 26a42d8 + fix d3a9e13) would be my next suspect.
What I hope will be the final version, with the USB3 commit, is now building.
Reacted by ChrisWorks great! It's been a journey...
- added a commit that references this issue
on Oct 5, 2026 Thus ends the saga.
- added a commit that references this issue
on Oct 5, 2026
Describe the bug
The mainline rtw89 driver gained USB support for the RTL8852AU in 6.19 (CONFIG_RTW89_8852AU, e.g. TP-Link Archer TX35U). The Kconfig entry is present in rpi-6.19.y and later, but the option is not set in bcm2711_defconfig, bcm2711_rt_defconfig or bcm2712_defconfig, while RTW89_8851BU and RTW89_8852BU already are (#7096).
Could it be enabled as
CONFIG_RTW89_8852AU=m? And would a backport to rpi-6.18.y be feasible, as seems to have been done for 8852BU? Currently the only option on Pi OS is an out-of-tree DKMS driver.Device: Raspberry Pi 4B, 6.12.109+rpt-rpi-v8 (an upgrade to trixie/6.18 is planned), adapter USB ID 3625:010f (Realtek 802.11ax WLAN Adapter - 3625:010f is already in the mainline rtw8852au.c device table, so enabling the option should be sufficient for this adapter).
Steps to reproduce the behaviour
Any clean install of Pi OS
Device (s)
Raspberry Pi 4 Mod. B
System
Raspberry Pi 4 Model B Rev 1.1
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
Raspberry Pi reference 2024-03-15
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, f19ee211ddafcae300827f953d143de92a5c6624, stage2
Linux raspberrypi 6.12.109+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.109-1+rpt1 (2026-09-11) aarch64 GNU/Linux
Revision : c03111
Model : Raspberry Pi 4 Model B Rev 1.1
Throttled flag : throttled=0x0
Camera : supported=0 detected=0, libcamera interfaces=0
USB Information
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=rtw89_8852au_git, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 4, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
|__ Port 4: Dev 5, If 0, Class=Mass Storage, Driver=uas, 480M
Logs
No response
Additional context
No response