Claude review: accel: ethosu: Remove redundant job_lock

[Claude Code Review Bot <claude-review@example.com>]

Overall Series Review

Subject: accel: ethosu: Remove redundant job_lock
Author: =?UTF-8?q?Ma=C3=ADra=20Canal?= <mcanal@igalia.com>
Patches: 1
Reviewed: 2026-05-18T16:46:56.799851

---

This is a single, well-reasoned patch that removes a redundant `job_lock` mutex from the ethosu accelerator driver, replacing it with `READ_ONCE`/`WRITE_ONCE` on `dev->in_flight_job`. The commit message provides an exceptionally thorough analysis of the three concurrency scenarios.

The approach is **correct**. The key invariants that make it safe:

1. **`credit_limit = 1`** (line 296) — only one job can be in-flight, so `run_job()` is never called while another `run_job()` is active.
2. **Scheduler serializes `run_job()` and `timedout_job()`** — they are mutually exclusive callbacks.
3. **IRQ handler clears `in_flight_job` before `dma_fence_signal()`** — so any `run_job(next)` woken by the signal sees NULL and can safely store the new job pointer.
4. **Memory ordering is sufficient** — `writel()` at the end of `ethosu_job_hw_submit()` includes a write barrier (ensuring `in_flight_job` is visible before HW is kicked), and `dma_fence_signal()` uses spinlocks internally (providing acquire/release semantics that order the NULL store relative to the wake-up of the next `run_job()`).
5. **`job_lock` is fully removed** — grep confirms zero remaining references.

**One caveat**: the author notes this is compile-tested only (no hardware). Given the subtle concurrency changes, hardware testing or careful review from the ethosu maintainer would be prudent before merging.

**Verdict: Looks good.** The analysis is sound and the code change matches the stated rationale.

---

---
Generated by Claude Code Patch Reviewer