Claude review: drm/i915/selftests: Fix build after dma-fence locking rework

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

Patch Review

The patch replaces direct `fence->lock` access with the new `dma_fence_spinlock()` accessor in two places:

> -	spin_lock_irq(fence->lock);
> +	spin_lock_irq(dma_fence_spinlock(fence));
>  	__list_del_entry(&active->cb.node);
> -	spin_unlock_irq(fence->lock); /* serialise with fence->cb_list */
> +	spin_unlock_irq(dma_fence_spinlock(fence)); /* serialise with fence->cb_list */

This is a straightforward mechanical change. Both the lock and unlock use the same accessor on the same `fence` pointer, so the lock/unlock is properly balanced. The `fence` pointer is non-NULL at this point (guarded by the `if (!fence) return;` above).

The commit message accurately describes both the problem and the fix, and correctly identifies the commit that caused the build breakage via the Fixes tag.

Christian's question in the review thread about `spin_lock_irq()` vs `spin_lock_irqsave()` is worth noting. Looking at the existing tree, `active_flush()` is called from `i915_active_unlock_wait()` under `rcu_read_lock()`, which does not alter IRQ state. The selftest calling context is process context with interrupts enabled, so `spin_lock_irq()` is technically fine here. But that's a pre-existing design choice, not something this patch introduces or changes.

No issues found in this patch.

---
Generated by Claude Code Patch Reviewer