Claude review: drm/panthor: Use guards for resv locking

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

Patch Review

Clean application of the dma_resv guards from patch 2. Straightforward conversions from `dma_resv_lock()/dma_resv_unlock()` to `guard(dma_resv)`.

**`panthor_gem.c` — `nonblocking_page_setup()` behavior change:**
```c
ACQUIRE(dma_resv_try, resv_guard)(bo->base.resv);
if (ACQUIRE_ERR(dma_resv_try, &resv_guard) || !bo->backing.pages)
    return VM_FAULT_RETRY;
```
The original code checked `dma_resv_trylock()` failure separately from `!bo->backing.pages`. Both returned `VM_FAULT_RETRY`. Combining them is correct and cleaner.

**`panthor_mmu.c` — `panthor_vm_prepare_map_op_ctx()`:**
The final two stanzas become:
```c
guard(dma_resv)(panthor_vm_resv(vm));
drm_gpuvm_bo_extobj_add(op_ctx->map.vm_bo);
...
guard(dma_resv)(bo->base.resv);
guard(mutex)(&bo->base.gpuva.lock);
panthor_gem_update_reclaim_state_locked(bo, NULL);
```
Wait — both `guard(dma_resv)` calls will hold their locks until the end of the function. In the original code, `panthor_vm_resv(vm)` was unlocked before `bo->base.resv` was locked. If `bo->base.resv != panthor_vm_resv(vm)` (which is the condition for entering the `if` block), these are different objects and holding both simultaneously shouldn't deadlock. But this does extend the hold time of the VM resv lock. This is likely fine in practice since the additional work is just a mutex lock and a function call.

---
Generated by Claude Code Patch Reviewer