Claude review: drm/amdgpu: use spin_lock_irqsave for PASID IDR lock

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

Patch Review

**Status: Good**

Converts all three lock sites to `spin_lock_irqsave`/`spin_unlock_irqrestore`:

1. **`amdgpu_pasid_alloc()`** — process context allocator
2. **`amdgpu_pasid_free()`** — called from both process and hardirq context (via `amdgpu_pasid_free_cb`)
3. **`amdgpu_pasid_mgr_cleanup()`** — module cleanup

All three conversions are correct and follow the same pattern:
```c
+	unsigned long flags;
 ...
-	spin_lock(&amdgpu_pasid_idr_lock);
+	spin_lock_irqsave(&amdgpu_pasid_idr_lock, flags);
 ...
-	spin_unlock(&amdgpu_pasid_idr_lock);
+	spin_unlock_irqrestore(&amdgpu_pasid_idr_lock, flags);
```

**Minor nit**: In `amdgpu_pasid_free()`, the `flags` variable declaration is placed before the `trace_amdgpu_pasid_freed()` call with no blank line separating declarations from statements:

```c
void amdgpu_pasid_free(u32 pasid)
{
+	unsigned long flags;
 	trace_amdgpu_pasid_freed(pasid);
```

Kernel coding style typically expects a blank line between variable declarations and the first statement. Looking at the applied result, it does have the declaration immediately followed by the trace call with no blank line. This is a cosmetic nit — some maintainers care, some don't.

**Correctness note on `amdgpu_pasid_mgr_cleanup()`**: Using `spin_lock_irqsave` here is technically unnecessary since this runs during module unload where no concurrent IRQ-context users should exist, but it's the right thing to do for consistency — it ensures the lock annotation is uniform across all call sites, preventing future lockdep warnings if the call ordering ever changes.

---
Generated by Claude Code Patch Reviewer