RTL8821AU: remove redundant PR #37 trace-derived post-fwdl pokes#43
Open
josephnef wants to merge 1 commit into
Open
RTL8821AU: remove redundant PR #37 trace-derived post-fwdl pokes#43josephnef wants to merge 1 commit into
josephnef wants to merge 1 commit into
Conversation
Drops 113 lines from `HalModule::rtl8812au_hal_init`'s `if (CHIP_8821)` post-fwdl block: - Hardcoded T2U Plus MAC at 0x0610..0x0615 - ~13 trace-captured register pokes (0x004c, 0x004e, 0x0040, 0x0208, 0x0520, 0x0670, 0x0a0a, 0x1874-0x187f) - BB/AGC value overrides (0x0830/0834/8a4/8b0, 0x0c20-0x0c44, 0x0c50/ 0c54/0c90/0cb4/0e90) - Mislabeled "8814 post-fwdl init" RRSR / queue-ctrl / RA-table block (was inside the 8821 branch — wrong comment header) writing 0x0440, 0x04bc, 0x04c6, 0x0520 (second value, overwriting first), 0x0524, 0x0670 (second value), 0x0990-0x09a4 All originally captured from an aircrack-ng/88XXau cold-init usbmon trace in PR #37 to compensate for master's flat 8821 init path. The double-writes to 0x0520 and 0x0670 (different values per write) were a smell that the trace replay had never been fully reasoned through. PR #42's proper 8821-specific init flow makes this block redundant — the chip lands in MAC-RX-ready state from any starting condition without needing the trace replay. ## Validation Linux full matrix on 8814AU + 8821AU T2U Plus, channel 100, VM mode. No regressions on 8821 cells; counts within normal RF variance: | TX → RX | post-#42 (with trace pokes) | this PR | |-------------------------------|-----------------------------|---------| | 8814 kernel → 8821 kernel | 430 ✓ | 435 ✓ | | 8814 kernel → 8821 devourer | 400 ✓ | 400 ✓ | | 8821 kernel → 8814 kernel | 365 ✓ | 372 ✓ | | 8821 devourer → 8814 kernel | 5865 ✓ | 5933 ✓ | 8814-TX cells (2, 4) and 8814-RX cells (7, 8) unchanged at 0 — known separate issues. ## What this PR doesn't validate Android-side hotplug end-to-end. PR #42 was confirmed by @RomanLut to fix hotplug on PixelPilot + hx-esp32cam-fpv with the trace pokes still applied. This PR removes them — re-validation needed to confirm the proper init flow alone is sufficient. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cleanup follow-up to #42. Drops 113 lines from
HalModule::rtl8812au_hal_init'sif (CHIP_8821)post-fwdl block — the trace-replay parity originally added in #37, now made redundant by #42's proper 8821-specific init flow.What's removed
Inside the
if (CHIP_8821)branch:The double-writes to 0x0520 and 0x0670 (different values per write within the same
if (CHIP_8821)block) were the smell — the trace replay had never been fully reasoned through. PR #42's proper init lands the chip in MAC-RX-ready state from any starting condition, making the replay unnecessary.Linux validation
tests/regress.py --full-matrix --channel 100on 8814 + 8821 T2U Plus, VM mode. No regressions; 8821 cells preserved within RF variance:8814-TX cells (2, 4) and 8814-RX cells (7, 8) unchanged at 0 — known separate issues.
What this doesn't validate
Android-side hotplug end-to-end. PR #42 was confirmed by @RomanLut to fix hotplug on PixelPilot + hx-esp32cam-fpv with the trace pokes still in place. This PR removes them. Proper init flow alone should be sufficient (that's the whole point of #42 — driving the chip from any starting state without relying on pre-captured pokes that matched one specific state) — but it deserves re-validation.
@RomanLut — when you have a moment, could you re-build PixelPilot / hx-esp32cam-fpv against this branch and confirm hotplug still works on 8821AU? Single replug cycle is enough. If it regresses, the trace pokes were load-bearing for hotplug specifically (unlikely IMO but possible) and we revert.
What this PR doesn't touch
if (is_8814a)block at the top of the same area still programs the hardcoded MAC and theDEVOURER_OOT_REPLAY=1-gated path; unchanged.Test plan
--full-matrixno regressions on Linux🤖 Generated with Claude Code