Claude review: drm/vblank: Introduce deferred vblank enable/disable

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

Patch Review

This is the core patch and has the most substance. The design — wrapping `drm_vblank_enable()`/`vblank_disable_fn()` in workers with pre/post callbacks — is reasonable. However, several issues need attention:

**Issue 1: Unconditional workqueue allocation**

```c
dev->deferred_vblank_wq = alloc_workqueue("drm_vblank_deferred_wq",
                                          WQ_HIGHPRI | WQ_UNBOUND, 0);
if (!dev->deferred_vblank_wq)
    return -ENOMEM;
```

This is allocated for **every** DRM device in `drm_vblank_init()`, even though the vast majority of drivers will never use deferred vblank. Only devices implementing the `pre/post_enable/disable_vblank` callbacks need this workqueue. The allocation (and init of `enable_work`, `disable_work`, `enable_done` per-CRTC) should be deferred or conditional. One approach: allocate it lazily on first use, or check at CRTC init time if any CRTC needs it.

**Issue 2: Missing cancellation of pending deferred work in drm_crtc_vblank_off()**

The patched `drm_crtc_vblank_off()` calls `pre_disable_vblank` and `post_disable_vblank` directly, and calls `drm_vblank_disable_and_save()` under the spinlock. But it does **not** cancel any pending deferred `enable_work` or `disable_work`.

Consider this race:
1. `drm_vblank_get()` queues `enable_work` to the deferred workqueue
2. Before the worker runs, `drm_crtc_vblank_off()` is called (modeset)
3. `vblank_off` disables vblank and sets `inmodeset`
4. The queued `enable_work` now runs, takes `vbl_lock`, calls `drm_vblank_enable()` — which checks `!vblank->enabled`, sees it's false, and **re-enables vblank** after `vblank_off` has already shut everything down

This could lead to vblank interrupts firing on hardware that the driver expects to be quiesced. `drm_crtc_vblank_off()` should `cancel_work_sync(&vblank->enable_work)` and `cancel_delayed_work_sync(&vblank->disable_work)` (after dropping spinlocks, before or after the existing `drm_vblank_flush_worker()` call).

Similarly, `drm_crtc_vblank_on_config()` should cancel any pending deferred `disable_work` to avoid a stale disable racing with the new enable.

**Issue 3: Cosmetic extra parentheses**

```c
if ((!needs_deferred_enable && !vblank->enabled)) {
```

The outer parentheses are unnecessary.

**Issue 4: Comment style**

```c
/* Initialize in the completed state, the first deferred vblank
 * enable will reinitialize this. */
```

Kernel multi-line comment style puts `*/` on its own line:
```c
/*
 * Initialize in the completed state, the first deferred vblank
 * enable will reinitialize this.
 */
```

---
Generated by Claude Code Patch Reviewer