rtl8811au support

[RomanLut]

Attempt to add rtl8811au support.

Still no luck, waiting for hardware.

The missing parts were taken from https://github.com/svpcom/rtl8812au/tree/v5.2.20-rssi-fix-but-sometimes-crash

[josephnef]

Thanks for porting this — adding the 8821a HAL tree is exactly the missing piece for actual RTL8821AU dongles. Two coordination notes plus one logistics ask.

Scope / dispatch. The PID allow-list in RtlUsbAdapter::InitDvObj currently lumps real RTL8811AU PIDs (0bda:0811, 0bda:a811) into RtlChipType::RTL8821. Those are Jaguar silicon (CHIP_8812 with RFType=1T1R), not Jaguar2 — sending them through the 8821 HAL with the 8821 firmware blob shouldn't work. Suggest narrowing the table to genuinely-8821 SKUs (e.g. 2357:0120, 0bda:0820/0821/0823, the 8821-combo OEM IDs) and letting the existing 8812 path handle 8811AU. Even better long-term would be a SYS_CFG-based family check (IC-ID bits) so new SKU revs don't need a code patch — that's what upstream rtl8812au does.

Conflict with #21. I have a small PR open (#21) that touches the same lines in EepromManager::read_chip_version_8812a — it derives RFType from REG_SYS_CFG bit 27 (RF_TYPE_ID) so the already-present 1T1R BB/RF paths reach actual 8811AU dongles. Whichever lands first will force the other to rebase. Happy to coordinate — I think the two compose cleanly once #22's dispatch is narrowed:

• rtl8811au support #22's family detect chooses CHIP_8821 vs CHIP_8812 HAL tree
• inside CHIP_8812, Add RTL8811AU support via RF_TYPE_ID autodetect #21's SYS_CFG read picks 1T1R vs 2T2R

Hardware / logistics. The reporter on #20 (BadPotato1007) has a TP-Link Archer T2U Plus (2357:0120) — that's already in your allow-list — and is up for testing #22, which would close the loop. Also: we'd like to keep one in the OpenIPC lab for regressions. Where did you source / where are you planning to source your test dongle from? Happy to order from the same place so we're testing against an identical SKU rev.

[RomanLut]

Where did you source / where are you planning to source your test dongle from?

https://www.amazon.de/-/en/dp/B07P681N66?ref=ppx_yo2ov_dt_b_fed_asin_title&th=1
I hope correct chipset arrive. You may wait a few days untill I check.

[josephnef]

Putting this on hold — RTL8811AU support landed via #23 (squash-merged f05b743), so master now carries the 8811 code path. We'd like to keep this PR around as a second-source data point but are postponing review/merge until we have RTL8811AU hardware in hand to verify against before integrating any deltas. Thanks for the contribution.

[josephnef]

Hardware test (2026-05-23). Finally got a TP-Link Archer T2U Plus (2357:0120, RTL8821AU) in-lab on a Mac. Ran current master (5de6d62) against it to characterise the failure mode before re-attempting this PR.

RX and TX die at the same stage:

<devourer>read_chip_version_8812a SYS_CFG(0xF0)=0x04412535
<devourer>Chip Version Info: CHIP_8812_Normal_Chip_TSMC_D_CUT_2T2R_RomVer(0)
... (EFUSE autoload OK, sensible defaults) ...
<devourer>power-on :REG_SYS_CLKR 0x09=0x30. REG_CR 0x100=0xEA
<devourer>MAC has not been powered on yet
<devourer>InitPowerOn: run power on flow fail

Master applies Rtl8812_NIC_ENABLE_FLOW to 8821AU silicon and HalPwrSeqCmdParsing returns false — chip stays in CARDEMU, never transitions to ACT. This is exactly what your hal/Hal8821APwrSeq.{c,h} is for. USB open / claim / reset / EFUSE autoload all work; the gap is purely in the HAL.