fix: 8821AU ch100 chip wedge on second channel-set during init (issue #59)

[josephnef]

Summary

Closes the 8821AU UNII-2/3 RX-side gate from issue #59. The 6+ prior hypotheses tested in kaeru:8821au-5ghz-unii2-tx-gate-five-hypotheses-refuted-2026-06-01 all focused on TX-out registers. The real bug was elsewhere: 8821AU wedges mid-init at ch100 if the channel-set runs twice during devourer's rtw_hal_init.

Root cause

HalModule::rtw_hal_init invokes two channel-sets back-to-back:

1. rtl8812au_hal_init() hardcoded registry_priv::channel = 36 (compile-time default) for the initial channel-set.
2. init_hw_mlme_ext(selectedChannel) reset state (_currentChannel = 0, current_band_type = BAND_MAX) and re-ran the channel-set with the user's actual channel.

For most chip/channel combos the second pass is wasted work. For 8821AU at ch100 specifically, the SECOND phy_SwChnlAndSetBwMode8812 wedges the chip mid-TX-power-write loop — chip stops ACK'ing USB vendor control transfers after the 2nd or 3rd BB write, leaving the demo deadlocked on libusb_control_transfer until SIGKILL.

Confirmed not caused by band switch (test with registry_priv::channel = 100 → both passes at ch100, second still wedges). Some 8821-specific UNII-2 BB state the first init leaves behind makes the chip reject the second pass's reprogramming.

Fix

Two complementary changes:

1. HalModule::rtl8812au_hal_init(uint8_t init_channel) — parameterise the initial channel-set so init runs directly at the user's selected channel, not at the registry default. With this, both init passes target the same channel → init_hw_mlme_ext has nothing to do.

2. init_hw_mlme_ext — when the chip is 8821AU AND the post-init state already matches the requested channel/bw/offset, skip the reset-and-redo and just call Set_HW_VAR_ENABLE_RX_BAR. Chip-gated to 8821 only because some 8814AU init paths depend on the second-channel-set side effects (initial gating-by-default regressed 8814 ch6 RX loop entry).

The fix preserves historical behaviour byte-for-byte for 8812AU and 8814AU.

Verification

Cell	Pre-fix	Post-fix
8821-dev init at ch100	chip wedges mid-TX-power loop	reaches RX loop ✓
8814-ker TX → 8821-dev RX @ ch100	0 / 442 ✗	400 / 444 ✓
8821-dev TX → 8814-ker RX @ ch100	works	works ✓ (unchanged)
8814 ch6 RX loop entry	works	works ✓ (chip-gated preserves 8814 path)
8821 ch6 RX loop entry	works	works ✓

Test plan

• 8821 ch100: chip no longer wedges; RX loop runs; receives frames within seconds.
• 8814 ch6: RX loop still works (regression-checked after the initial unfiltered version of the fix had broken it).
• 8821 ch6: still works.
• 8814-ker TX → 8821-dev RX @ ch100 cell: closed (was the documented UNII-2/3 RX-side gate per README).
• Full matrix at ch6/ch36/ch100 across all 3 adapters: pending — 8812 dongle dropped off USB and 8821-related test sequencing wedges hardware intermittently. Targeted single-cell tests confirmed the fix; the full matrix re-run can land after the rig stabilises.

Remaining 8821 gaps (out of scope for this fix)

• 8814 RX at 5G broken — separate issue, pre-existing.
• 5GHz dev-dev gap when both ends are 8821-dev — pre-existing, not investigated yet.
• 8812-receiver-side asymmetry at UNII-2/3 — pre-existing, untested in this PR (8812 dongle dropped during test prep).

🤖 Generated with Claude Code