[josephnef]

Closes the last item on #504: the stop-during-Init matrix on the three backends the first round could not reach.

• --fw-dir on the probe (FW_DIR on the script, DEVOURER_MT7612U_FW_DIR env) names the decompressed mt7662.bin + mt7662_rom_patch.bin for an MT7612U, whose firmware is not embedded.
• A bring-up that throws out of Init is caught on the Init thread and reported as INIT_THREW with its message. Before this it escaped the thread and dumped core with no RESULT line, which is how every MT7612U cell first read.
• README: the MT7612U command, and why its reported Init-return time is near zero (the stop call blocks on the lock bring-up holds, so it returns when bring-up ends and Init leaves right behind it).

Measured through the script at this commit, ch6, no kernel driver on the DUT:

backend	Init returns after a stop at 100 / 400 / 1000 / 2500 ms	restart after stop	stale stop before Init
8812AU (Jaguar1)	1801 / 1469 / 895 / 30 ms	OK, 290 frames	OK, 240 frames
RTL8733B	2033 / 1579 / 965 / 40 ms	OK, 253 frames	OK, 264 frames
MT7612U	~0 ms, see above	OK, 178 frames	OK, 282 frames

18/18 on each; the verify loop after every honoured stop saw 158 to 1392 frames. With #505 that is all six backends.

🤖 Generated with Claude Code

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Enable MT7612U stop-during-Init tests and report bring-up errors

🐞 Bug fix 🧪 Tests 📝 Documentation 🕐 10-20 Minutes

AI Description

• Pass an MT7612U firmware directory into the stop-during-Init probe so hardware tests can run.
• Report Init exceptions as INIT_THREW results instead of terminating without a result.
• Document the MT7612U command and explain its near-zero reported Init return time.

Diagram

graph TD
  Script["Test script"] --> Probe["Stop probe"] --> Config["Device config"] --> Radio["MT7612U radio"]
  Probe --> Thread["Init thread"] --> Result["RESULT output"]
  Thread --> Radio
  Probe --> Result

Loading

High-Level Assessment

Keep firmware selection in DeviceConfig rather than reading the environment inside the radio; this follows the existing library boundary. Catching exceptions on the Init thread is necessary to produce a probe result instead of terminating the process.

Files changed (3) +44 / -4

Bug fix (1) +31 / -1

stop_during_init_probe.cppConfigure firmware and report Init exceptions +31/-1

Configure firmware and report Init exceptions

• Accepts '--fw-dir' or 'DEVOURER_MT7612U_FW_DIR' and places the directory in DeviceConfig. Catches standard exceptions on the Init thread and emits a failing 'INIT_THREW' result, whether the failure is observed before or after the scheduled stop.

tests/stop_during_init_probe.cpp

Tests (1) +6 / -0

stop_during_init.shForward MT7612U firmware directory to the probe +6/-0

Forward MT7612U firmware directory to the probe

• Accepts 'FW_DIR' and passes it as '--fw-dir' when set. Adds an example command and identifies the required decompressed firmware files.

tests/stop_during_init.sh

Documentation (1) +7 / -3

README.mdDocument MT7612U setup and stop timing +7/-3

Document MT7612U setup and stop timing

• Adds the MT7612U test command, its firmware-directory requirement, and the 'INIT_THREW' outcome. Explains why a stop blocked by bring-up can yield a near-zero measured Init return time and records coverage across six backends.

tests/README.md

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Bring-up errors can break result parsing ✓ Resolved

Description

The new INIT_THREW result interpolates the raw exception message into a machine-readable stdout
line without escaping it. An exception containing a quote or newline, including one originating from
firmware-path or device errors, produces malformed or multiple result records for the probe's
parser.

Code

tests/stop_during_init_probe.cpp[R172-173]

+    std::printf("RESULT mode=%s outcome=INIT_THREW what=\"%s\"\n", mode.c_str(),
+                init_what.c_str());

Evidence

The changed probe emits INIT_THREW directly to stdout and places the unescaped exception text
inside a quoted field. This conflicts with the requirement that machine events remain reliably
parseable and line-delimited.

CLAUDE.md: Maintain Structured Event and Diagnostic Logging Contracts: CLAUDE.md: Maintain Structured Event and Diagnostic Logging Contracts: CLAUDE.md: Maintain Structured Event and Diagnostic Logging Contracts: CLAUDE.md: Maintain Structured Event and Diagnostic Logging Contracts
tests/stop_during_init_probe.cpp[172-173]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
Issue description
The `INIT_THREW` stdout record inserts `init_what` verbatim inside a quoted field, so diagnostic text containing quotes or newlines can violate the machine-event logging contract and corrupt result parsing.
Fix Focus Areas
- tests/stop_during_init_probe.cpp[172-173]
- tests/stop_during_init_probe.cpp[192-193]
Recommended Fix
Serialize the `INIT_THREW` event through the same structured-event path used by the logging contract, escaping quotes, backslashes, and control characters and ensuring the event is emitted as one complete flushed stdout record. Keep detailed human diagnostics on stderr if they cannot be safely represented in the machine event.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. The probe can test unintended firmware ✓ Resolved

Description

The probe assigns --fw-dir to the device configuration without checking it, while
resolve_fw_dir() tries system and local directories if the supplied directory lacks either
firmware file. When an explicit path is wrong but a fallback contains both files, the matrix can
pass using different firmware, and the script deletes the log that identifies the directory actually
used.

Code

tests/stop_during_init_probe.cpp[R120-121]

+  if (!fw_dir.empty())
+    cfg.mt7612u.firmware_dir = fw_dir;

Evidence

The new option is assigned to the configuration, but the backend treats that directory as the first
candidate rather than a required source. The script captures the backend's firmware-source log and
removes it after a passing matrix.

tests/stop_during_init_probe.cpp[89-90]
tests/stop_during_init_probe.cpp[119-123]
src/mt7612u/Mt7612uRadio.cpp[31-48]
tests/stop_during_init.sh[64-80]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
An invalid explicit firmware directory can silently fall back to other firmware, so a passing probe run need not use the files the caller selected.
## Fix Focus Areas
- tests/stop_during_init_probe.cpp[119-123]
## Recommended Fix
Before creating the radio, require both expected firmware files to exist when a nonempty directory was explicitly supplied. Report a clear failure for an invalid directory; preserve the backend's normal fallback behavior when no directory was supplied.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗