8814: run PHY_SwitchWirelessBand8814A at initial band-set (fixes 5GHz RX, #51)

[josephnef]

What

The RTL8814AU received nothing at 5 GHz (#51): every devourer-RX cell on the 8814 returned 0 frames at 5 GHz while 2.4 GHz worked, with the bulk-IN endpoint timing out (LIBUSB_ERROR_TIMEOUT).

Root cause

HalModule::rtl8812au_hal_init ran PHY_SwitchWirelessBand8812 unconditionally at the initial band-set — even for CHIP_8814A. The 8812 band-switch marks the band already-set via the CCK-check register, so phy_SwBand8812's later per-chip dispatch (which does correctly choose the 8814A path) sees BandToSW == Band and skips PHY_SwitchWirelessBand8814A entirely.

The 8814 therefore never ran its 5 GHz band-switch: the path-C/D RFE pinmux (0xCB0/0xEB0/0x18B4/0x1AB4 via phy_SetRFEReg8814A), the 8814 AGC-table register, and the CCK clock-gate cycle stayed at frozen ch6-replay values. The 5 GHz RX front-end was misrouted, so the chip never handed frames to the bulk pipe.

Fix

Dispatch on chip type at the initial band-set, mirroring the dispatch already in phy_SwBand8812. PHY_SwitchWirelessBand8814A is made public for the call. (This also incidentally fixes a latent bug where current_band_type stayed at 2.4G on 5 GHz channels — it is set correctly inside PHY_SwitchWirelessBand8814A.)

How it was found

A kernel (aircrack-ng/rtl8814au, run in a pinned-kernel VM) vs. devourer usbmon register diff: devourer's runtime 0xCB0 read 0x77337717 instead of the correct type-1 5 GHz value 0x33173317, proving phy_SetRFEReg8814A never executed — which traced back to the wrong band-switch being called. A static source read alone was misleading: phy_SetRFEReg8814A had the right value; the function was simply never invoked.

Validation — real hardware (RTL8814AU 0bda:8813)

devourer-TX → devourer-RX, canonical-SA beacon:

Channel	Band	Before	After
ch6	2.4 GHz	~8800	~11000 (no regression)
ch36	5 GHz UNII-1	0	~21900
ch100	5 GHz UNII-2	0	18000–34500

Bulk-IN timeouts gone; 5 GHz RX surfaces tens of thousands of frames. The kernel aircrack-ng/rtl8814au driver was used as the on-bench reference (it RXes this exact dongle fine at 5 GHz), confirming the dongle hardware is sound and the gate was software.

Not covered by this PR

• ch149 (5 GHz UNII-3, the RF_MOD_AG=0x501 sub-band) isn't yet validated on a fresh chip — it uses the identical channel-set path as ch36/ch100 (only two register constants differ), so it's expected to work.
• 8814 TX on-air is not validated here. The same band-switch programs the RFE pinmux / path config that TX shares with RX, so this may also help the long-standing 8814 TX gate — to be tested separately.

🤖 Generated with Claude Code