Claude review: drm/imagination: Synchronize interrupts before suspending the GPU

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

Patch Review

**Correctness of the fix:**

The core change is sound. Adding `synchronize_irq()` between the firmware power-off request and `pvr_fw_stop()` ensures any in-flight threaded IRQ handler completes before the GPU is actually stopped:

```c
+	if (rpm_suspend) {
+		/* Wait for late processing of GPU or firmware IRQs in other cores */
+		synchronize_irq(pvr_dev->irq);
+	}
+
 	return pvr_fw_stop(pvr_dev);
```

`synchronize_irq()` waits for both hardirq and threaded IRQ handlers to complete, which is exactly what's needed given the crash trace shows `pvr_device_irq_thread_handler` as the offending function.

**Placement is correct:** The call is placed after `pvr_power_request_pwr_off()` (which tells the firmware to stop generating new interrupts) but before `pvr_fw_stop()` (which actually powers off the GPU). This ordering ensures: (1) no new IRQs will be generated by the firmware, and (2) any already-in-flight handler finishes before hardware access is revoked.

**Boolean parameter addition:**

```c
-pvr_power_fw_disable(struct pvr_device *pvr_dev, bool hard_reset)
+pvr_power_fw_disable(struct pvr_device *pvr_dev, bool hard_reset, bool rpm_suspend)
```

The two call sites are updated correctly:
- `pvr_power_device_suspend()` passes `true` — this is the runtime PM path that needs synchronization
- `pvr_power_reset()` passes `false` — this path already handles IRQs differently (via `disable_irq`/`disable_irq_nosync` earlier in the reset sequence, which on 6.12 would be just `disable_irq`)

**Minor observation — `synchronize_irq()` vs upstream's `disable_irq()`:**

The upstream drm-next version uses `disable_irq()` instead of `synchronize_irq()`, which is strictly stronger — it both synchronizes *and* prevents new IRQs from being delivered while the GPU is off. This backport's use of `synchronize_irq()` alone leaves a small theoretical window: a new IRQ could arrive (e.g., a spurious interrupt or shared IRQ line) after `synchronize_irq()` returns but before `pvr_fw_stop()` completes. In practice this is unlikely to be a problem since: (1) the firmware has already been told to power off, so it shouldn't generate new IRQs, and (2) the IRQ handler should handle spurious interrupts gracefully. The comment in the patch description acknowledges that this is a subset of the upstream fix, which is acceptable for a minimal stable backport.

**Commit message quality:** Good. Clearly explains the race condition, why it's different from the upstream commit, and provides a concrete crash signature. The `Fixes:` tag and `Cc: stable` are appropriate.

**No issues found.** The patch is a clean, minimal, and correct stable backport.

---
Generated by Claude Code Patch Reviewer