Claude review: drm/vmwgfx: Add some checks to vmw_cursor_plane_atomic_update

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

Patch Review

**Purpose:** Fix a null dereference when `old_state` is NULL in `vmw_cursor_plane_atomic_update`, found by IGT test `kms_cursor_legacy@torture-bo`.

**Issues:**

1. **Declaration-after-statement / mixed declarations and code (style):** The patch introduces variable declarations after statements, which violates the kernel coding style (and strict C89 rules still enforced by some kernel configs):

```c
new_state = drm_atomic_get_new_plane_state(state, plane);
if (!new_state)
    return;
old_state = drm_atomic_get_old_plane_state(state, plane);
struct drm_crtc *crtc =  new_state->crtc ? new_state->crtc :
    (old_state ? old_state->crtc : NULL);
if (!crtc)
    return;
struct vmw_private *dev_priv = vmw_priv(plane->dev);
```

The declarations of `crtc` and `dev_priv` appear after executable statements (the `if` guards). While C99/C11 allows this and the kernel has moved to C11, placing declarations like `struct drm_crtc *crtc` and `struct vmw_private *dev_priv` after `if` statements with `return` is unusual in kernel code. It would be cleaner to declare `crtc` at the top with `new_state`/`old_state` and assign it after the null checks.

2. **Double space:** Minor nit — there's a double space before `new_state->crtc`:
```c
struct drm_crtc *crtc =  new_state->crtc ? new_state->crtc :
```

3. **Can `new_state` actually be NULL here?** In the atomic commit path, `drm_atomic_get_new_plane_state` should always return non-NULL for a plane that is in the commit. If the plane is not in the atomic state, it shouldn't be called at all. The commit message says this fixes `kms_cursor_legacy@torture-bo`, but it would be helpful to understand the exact call path that leads to `new_state` being NULL — this might indicate the real bug is elsewhere (the plane shouldn't be in an update callback if it's not part of the state).

4. **Missing Fixes tag specificity:** The Fixes tag references the refactor commit but no explanation is given as to why the prior code (which used the same `drm_atomic_get_old/new_plane_state` calls) didn't trigger this. A sentence about the calling context would help reviewers.

---
Generated by Claude Code Patch Reviewer