AI-Assisted Driver Development

List the switch features and DSA operations used by V1, then check each operation against the target kernel's rules for call context, locking, sleeping, return values, and helper functions.

Follow driver start-up, DSA registration, setup, shutdown, and error paths across MDIO, phylink, interrupts, and managed resources to find ownership, lifetime, and partly completed setup problems.

Compare the binding YAML, examples, driver property handling, and compatibility needs, and record any hardware questions that must be answered before a safe change can be made.

Create one repeatable check command that saves logs and exit codes while running the chosen builds, warning checks, kernel code checks, and Device Tree binding and DTB checks.

Add separate Git work areas, allowed-command lists, time limits, retry limits, saved checkpoints, diff checks, recovery steps, and human approval before dangerous repository or lab actions.

Set up Sashiko for the chosen patch range, record its version and settings, and save its review results in a consistent format.

Mark every Sashiko finding as a code fix, a rejection backed by proof, a hardware question, or another human decision, and rerun all checks and Sashiko after each code change until no finding is left unresolved.

When a human turns on hardware testing, run a protected tmux-based test across the DUT serial console and test hosts, check machine identities, save timed logs, recover from failures, keep observations separate from guesses, and send runtime fixes back through all checks and Sashiko.

Turn the repairs into a patch series where each patch has one clear purpose, move it to the target submission base, check each required build point and the final result, and rerun Sashiko on the exact final patch range.

Prepare commit messages, a cover letter, a version-change list, replies to each reviewer, test evidence, the completed work list, open manual questions, remaining risks, and a clear final human decision on whether to submit.