jaguar3: 8822C 40/80 MHz bring-up calibrates IQK at 20 MHz, then retunes

[josephnef]

Closes #267.

The 8822CU brought up by devourer directly at 80 MHz received nothing — not even corrupt frames — while the identical code path worked on the 8822E as receiver, and the same chip received 80 MHz fine under both the vendor 88x2cu_ohd and the in-tree rtw88 drivers.

Root cause

Devourer ran the 8822C IQK with the RF tuned at 80 MHz. The vendor kernel never does that: it calibrates at its bring-up bandwidth and carries the coefficients across iw set freq … 80 — a usbmon capture of the kernel's 20→80 transition contains zero IQK-engine (0x1b00) traffic. IQK executed at 80 MHz loads RxIQC coefficients that leave the receiver unable to sync any frame.

Isolation was hardware-driven: full MAC+BB end-state value parity (327-register diff replayed, with BB-reset/IGI/RXBB re-applies) fixed nothing — the poison is write-only paged IQK state; replaying the kernel's captured 20→80 transition onto a 20 MHz bring-up worked (1741 frames), and DEVOURER_SKIP_IQK alone on a plain 80 MHz bring-up worked (1419 frames). The gap predates the #238 campaign (pre-campaign baseline equally dead — 80 MHz RX was simply never in the ground matrix).

Fix

For the 8822C at 40/80 MHz: tune 20 MHz on the target channel, run IQK there (the IQK command set follows the calibration width), then retune to the requested bandwidth. The 8822E keeps its existing flow (its 40/80 work with IQK-at-BW; left untouched deliberately).

Validation (two-adapter bench, ch36 primary / central 42, VHT1SS_MCS7/80)

cell	before	after
8812EU → 8822CU @80	0	4481 clean, EVM −48
8812AU → 8822CU @80	0	1545, −42
8822CU @40 (regression)	5226	4427, −52
8812EU TX ladder / CU hop parity / ctest	—	unchanged / PASS / 19/19

tests/cu_bb_endstate_diff_80.sh ships as the reproducer/diagnostic (vendor-kernel end-state diff at 80 MHz, /proc read_reg vs DEVOURER_BB_DUMP).

🤖 Generated with Claude Code