Claude review: drm/rockchip: vop2: Use vop2->old_layer_sel directly in wait_for_layer_cfg_done()

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

Patch Review

**Verdict: Correct but has a subtle consideration.**

This removes the `cfg` parameter from `rk3568_vop2_wait_for_layer_cfg_done()` since the only caller always passes `vop2->old_layer_sel`.

```diff
-static void rk3568_vop2_wait_for_layer_cfg_done(struct vop2 *vop2, u32 cfg)
+static void rk3568_vop2_wait_for_layer_cfg_done(struct vop2 *vop2)
```

And inside:
```diff
-				atv_layer_cfg == cfg, 10, 50 * 1000);
+				atv_layer_cfg == vop2->old_layer_sel, 10, 50 * 1000);
```

**Minor concern**: `readx_poll_timeout_atomic` re-evaluates the condition expression on each poll iteration. With the parameter version, the target value `cfg` was a stack copy captured before the loop started. With the new version, `vop2->old_layer_sel` is read from the struct on every poll iteration. If another thread (another VP's atomic commit) were to concurrently modify `vop2->old_layer_sel` while this spin is running, the target would shift mid-poll.

In practice, this is likely safe because:
- The function runs under `vop2->ovl_lock` mutex, and all paths that write `vop2->old_layer_sel` (after patch 3) also hold that mutex.
- So no concurrent writer should be able to change the value during the spin.

But this is worth noting — the parameter version was inherently immune to this class of bug, while the new version relies on the caller holding the mutex. If a future code path ever calls this function or modifies `old_layer_sel` without the lock, it would introduce a subtle bug. This is a reasonable tradeoff for code simplicity, but it might be worth a brief comment, or the maintainer may prefer keeping the parameter for robustness.

This is a style/maintainability judgment call rather than a correctness bug.

---

**Summary**: The series is well-crafted. Patches 1 and 2 are clear, correct bug fixes suitable for stable backport. Patches 3-5 are clean follow-up refactors. The only point worth discussing with the author is whether patch 5's removal of the explicit parameter is worth the implicit coupling to the mutex contract — but it's defensible either way.

---
Generated by Claude Code Patch Reviewer