Enable CONFIG_RTW89_8852AU (RTL8852AU/8832AU USB Wi-Fi 6)

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

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 module

I'm prepared to backport them to 6.18 - they apply cleanly - and add the extra config setting. As that what you had in mind?

@pelwell

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.

No 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.

That wasn't too bad - just three more commits. See #7649.

If you wait about 25 minutes you'll be able to install a trial 6.18 build including the new driver, but read the caveats first.

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.

Did 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=0 in config.txt without any other changes and seeing if it still boots.

I already tried auto_initramfs=0 with no success! I'll probably have the time to have a closer look during the next days.

@pelwell

@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.xz

However, 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_8852au

I 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=0 on 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?

I've added the extra dependency commits to #7649, and include 80119a7 as requested. The next auto-build should be ready in about 25 minutes.

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 1

I 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=m be feasible, to see whether current upstream behaves like the out-of-tree driver?

Let's go to 7.2 - 7.1 is already EOL. See #7670.

@pelwell

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.

#7649 is now up to 24 commits. The same procedure applies.

@pelwell

Works now! Tested in USB2 mode only because 8368970, "wifi: rtw89: usb: Support switching to USB 3 mode", v7.2, is not (yet? 😇) part of this backport.

Thanks @pelwell - really enjoyed how quick and pragmatic the iterations were.

What I hope will be the final version, with the USB3 commit, is now building.

Works great! It's been a journey...

configs: Enable RTW8852AU support

Thus ends the saga.

configs: Enable RTW8852AU support

Navigation Menu

Repository navigation

Enable CONFIG_RTW89_8852AU (RTL8852AU/8832AU USB Wi-Fi 6) #7646

Describe the bug

Steps to reproduce the behaviour

Device (s)

System

Logs

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Enable CONFIG_RTW89_8852AU (RTL8852AU/8832AU USB Wi-Fi 6) #7646

Description

Describe the bug

Steps to reproduce the behaviour

Device (s)

System

Logs

Additional context

Activity

pelwell commented on Sep 25, 2026

kleinc80 commented on Sep 25, 2026

pelwell commented on Sep 25, 2026

kleinc80 commented on Sep 25, 2026

pelwell commented on Sep 25, 2026

kleinc80 commented on Sep 25, 2026

pelwell commented on Sep 30, 2026

kleinc80 commented on Oct 1, 2026

pelwell commented on Oct 1, 2026

kleinc80 commented on Oct 1, 2026

kleinc80 commented on Oct 2, 2026

pelwell commented on Oct 2, 2026

kleinc80 commented on Oct 2, 2026

pelwell commented on Oct 2, 2026

kleinc80 commented on Oct 2, 2026

pelwell commented on Oct 2, 2026

kleinc80 commented on Oct 3, 2026

pelwell commented on Oct 5, 2026

kleinc80 commented on Oct 5, 2026

pelwell commented on Oct 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions