8822C: read_efuse_logical_map early-exit assumes logical-ordered EFUSE sections — empty map, rfe_type=0x00 on append-ordered units

[josephnef]

Found while reviewing #383 (hardware-verified there on a second, independent RTL8822CU — 2/2 units affected).

Symptom

On 8822C, HalJaguar3::read_efuse_logical_map returns a near-empty logical map: rfe_type reads 0x00, the new #383 MAC read at logical 0x157 finds 0xFF, and the TX-power-base walk is exposed to the same truncation. The physical OTP reads fine (efuse_OneByteRead works; the stability probe's id=0x8129 is correct).

Root cause

The non-EU walk has two terminations:

if (hdr == 0xFF)
  break;
...
if (base > upto + 8)
  break; /* past the byte we need */

The second one assumes EFUSE sections are burned in logical-offset order. They are append-ordered: each burn appends physically with whatever logical offset it carries. Physical dump of the affected unit (reader lambda logged inside the walk):

physdump 000: 00 29 81 00 8f ff 20 09  00 10 98 04 e4 31 10 03
physdump 010: f1 eb 0f 48 f0 94 65 d3  58 c5 2f 4e cd f0 4f 40
...
physdump 0d0: 46 46 4f 5e da 0b 4f 57  02 a8 6f 5e b5 8e 6f 5d
physdump 0e0: 6a 94 6f 5b ea 09 6f 57  03 52 8f 5e 65 61 8f 5d

At phys 0x12 sits header 0f 48 → logical offset 0x20 (logical byte 0x100). Every walk with upto ≤ 0xFA (rfe, tx-power base, the probe) hits base > upto + 8 there and exits after ~3 blocks — before ever reaching the sections that hold logical 0xCA (rfe) or 0x157 (MAC), which are further along physically (0xd2+).

Experiment (worktree, same unit)

• Control: EU-style 0xFF-run tolerance alone (the mechanism Expose the EFUSE MAC as a per-unit adapter identity #383's description suspected) — no change; MAC still unavailable, rfe_type still 0x00. That padding bug was the 8822E's, not this.
• Fix: remove the base > upto + 8 exit and walk to the 64-byte-0xFF-run end (as the EU branch already does):
  • MAC decodes: a8:b5:8e:6a:94:ea (stable across runs)
  • rfe_type flips 0x00 → 0x03

Why this needs its own validation, not a drive-by

The rfe_type change means append-ordered 8822C units are selecting the wrong PHY tables today, and fixing the walk changes table selection and per-channel TX-power base for every 8822C user. The fix itself is small, but it needs:

• on-air TX A/B (before/after) on an affected unit, per rate, SDR-measured
• a check that read_efuse_txpwr_base output changes are the intended ones (previously-missing bytes appearing, not previously-read bytes moving)
• a re-run of the Expose the EFUSE MAC as a per-unit adapter identity #383 doctor cross-check (wlx<mac> vs devourer) on 8822C once the walk reads far enough

Note the walk-cost change is bounded: the exit's replacement is the existing 64-byte-0xFF-run end-of-map rule, so a sparse map still terminates early.

[snokvist]

#384 is the fix for this (opened before the issue — same root cause, same base > upto + 8 exit; your control experiment ruling out the 0xFF-padding mechanism matches what I saw independently).

The validation asks are answered in #384 (comment), in short:

• read_efuse_txpwr_base output — cannot change on either variant. read_efuse_txpwr_base_8822e() returns early unless _variant == C8822E, and on 8822E the walk takes the EU branch, which returns before the removed exit ever ran. The full consumer set of the changed (non-EU) walk is read_efuse_rfe_type, probe_efuse_map, and Expose the EFUSE MAC as a per-unit adapter identity #383's MAC read.
• RFE blast radius — measured offline by walking all five 8822C tables through PhyTableLoaderJaguar3::Load at rfe_type 0 and 3 and diffing the write streams: identical write counts and identical address sets in every table, no row appearing or disappearing, and the whole delta is 7 RF register values (5 radio A, 2 radio B; BB, AGC and RFK cal-init untouched). Cut-independent across cut_version 0–3. Table in the PR comment.
• Vendor parser — eeprom_parser_88xx() (rtl88x2cu 20230728, halmac_efuse_88xx.c:1139) walks do { … } while (1) with no logical-offset bound, terminating only on hdr == 0xff and physical-size guards. The post-fix walk is the vendor's; the upto exit was devourer-local. It also settles the re-burn question: the vendor overwrites log_map[eeprom_idx] as it walks, and the measured unit does carry two sections at base 0x150.
• On-air per-rate A/B — the one I can't produce; no SDR here. I can run a link-level A/B on the affected 8822CU (fixed TX power and channel, N frames per MCS, before/after, per-MCS PDR + RSSI) if that is useful as a partial.

[josephnef]

Fixed by #384 (merged as 1c8ae57): the base > upto + 8 early-exit is removed, the walk decodes the whole programmed area (existing 0xFF-run terminator + a new kPhysMax guard against the 10-bit address aliasing), and the upto parameter is gone so the trap cannot be reintroduced by a caller.

Against the validation list this issue asked for:

• On-air TX A/B on an affected unit — done on this rig's 8822CU (MCS7/20, txdemo flood, SDR duty): 5 GHz ch36 a tie (49.2% vs 48.7%); 2.4 GHz ch6 78.6–81.8% → 92.5–94.2% across interleaved reps (per-arm sd < 1 point). The corrected rfe_type=0x03 front-end rows are a measured gain, not just a cosmetic byte — master was flying the unprogrammed-default tables on these units. Scope note: duty at one rate, not a per-rate delivery ladder; duty is rate-agnostic and the RX smoke A/B (345 vs 408 clean/8 s, 0 corrupt, HEALTHY both arms) covers the decode side.
• txpwr-base diff audit — moot as asked: read_efuse_txpwr_base_8822e is 8822E-only, and the 8822E branch of the walk is untouched (its efuse decoded (0x22=46 0x4c=51 0xca=15) line is identical before/after). The 8822C has no efuse txpwr base (flat JAGUAR3_TXPWR_REF_BASE_8822C).
• doctor cross-check — the 8822CU now decodes MAC a8:b5:8e:6a:94:ea (the exact value this issue's worktree experiment predicted), stable across runs; the author's unit cross-checks 40:a5:ef:2f:23:08 against the kernel's own netdev MAC. rfe_type=0x03 agrees with the kernel's efuse_map on both units.

2/2 independently-affected units verified.