Claude review: drm/i915/reset: Handle the display vs. GPU reset deadlock using a custom dma-fence

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

Patch Review

This is the core patch. Key design:

1. A `dma_fence` is lazily created on first request (`intel_display_reset_fence_get`) and stored in `display->reset.fence`, protected by `display->reset.mutex`.
2. `intel_atomic_commit_fence_wait()` gets the reset fence and waits on both the plane fence and the reset fence via `dma_fence_wait_any_timeout()`.
3. `intel_display_reset_prepare()` signals the reset fence before proceeding with the reset.
4. `intel_display_reset_finish()` discards the old (signaled) fence so the next caller gets a fresh one.

**Race concern — discard vs. in-flight waiters:** In `intel_display_reset_fence_discard()`, the fence is put (potentially freed) under the mutex. But a concurrent `intel_atomic_commit_fence_wait()` has already taken a reference via `dma_fence_get()`, so this is safe — the refcount protects against use-after-free. This is correct.

**Potential concern — signal ordering:** `intel_display_reset_prepare()` signals the fence first, then proceeds to take `mode_config.mutex` and modeset locks. The commit path, after waking from fence wait, proceeds into `intel_atomic_commit_tail()` which eventually calls `drm_atomic_helper_wait_for_dependencies()` etc. The reset path then acquires modeset locks. There could be a race where the commit proceeds and tries to do hardware access while the reset is in flight. However, this is the same as the original design intent — the fence wait unblocking lets the commit proceed to eventually release modeset locks that the reset needs. The commit path should not do harmful hardware access before the reset completes because the GPU is already hung.

**`dma_fence_init` with context=0, seqno=0:** Using `dma_fence_init(fence, &ops, NULL, 0, 0)` — context 0 with seqno 0 means all reset fences share the same context/seqno. This is fine for this use case since there's only ever one active reset fence at a time, and they are purely for signaling, not ordering. However, `dma_fence` debug infrastructure may complain about context 0 reuse. Consider using `dma_fence_context_alloc(1)` for a unique context.

**Missing `mutex_destroy` in cleanup:** `intel_display_reset_fence_init()` calls `mutex_init()` but there's no corresponding `mutex_destroy()` in the teardown path. `intel_display_driver_remove()` calls `intel_display_reset_fence_discard()` which discards the fence but doesn't destroy the mutex. Minor leak of debug resources on CONFIG_DEBUG_MUTEXES kernels.

**xe Makefile addition:** Adding `intel_display_reset.o` to the xe build is needed since `intel_display_reset_fence_get` is now called from shared display code. The compat stubs for `intel_clock_gating.h` from patch 4 make this build cleanly.

---
Generated by Claude Code Patch Reviewer