Claude review: drm/vmwgfx: Never destroy STDU zero's Screen Target

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

Patch Review

**Commit message:** Well written. Clearly explains the problem (client can't create a window, user can't wake VM), the root cause (Screen Target destroyed on disable), and the fix. The Fixes tag references the commit that introduced the "don't destroy on inactive" logic, which this patch extends.

**Code review:**

The change at `vmwgfx_stdu.c:455-456`:
```c
if (stdu->base.unit == 0)
    return;
```

This is placed after the bind-to-NULL + update sequence (lines 437-441) which blanks the display, and after the existing early return for the "enabled but inactive" case (lines 446-449). So unit 0's Screen Target will still be unbound/blanked — it just won't be destroyed. This is the right behavior: the display goes dark but the ST metadata remains for clients to query.

**Minor concern — skipped `content_fb_type` reset:** When we early-return for unit 0, we also skip the `stdu->content_fb_type = SAME_AS_DISPLAY` assignment at line 462. This is the same situation as the existing early return at line 449, which also skips it, so this is consistent with the existing pattern. However, it's worth noting that `mode_set_nofb()` (line 395-399) always destroys and resets `content_fb_type` before re-defining, so the re-enable path should handle this correctly regardless.

**Interaction with `mode_set_nofb`:** When the CRTC is re-enabled, `vmw_stdu_crtc_mode_set_nofb()` checks `stdu->defined` (line 388) and will destroy + recreate the Screen Target with the new mode. Since we leave `stdu->defined = true` for unit 0, this path works correctly — it will tear down and rebuild as needed.

**No leak on driver teardown:** `vmw_stdu_destroy_st()` checks `stdu->defined` at the top (line 340) and is a no-op if false. Since unit 0 keeps `defined = true`, any cleanup path that calls `destroy_st` will still properly clean up. This looks safe.

**Comment style:** The multi-line comment uses `/* ... */` style which is fine but the kernel generally prefers the opening `/*` on its own line for multi-line comments (network-style). The existing comment above (lines 443-445) uses the same style, so this is at least locally consistent. Not a blocker.

**Overall:** Clean, minimal fix. The approach of special-casing unit 0 is pragmatic — it's the primary display and the one clients will look for. No correctness issues identified.

**Reviewed-by worthy: Yes.**

---
Generated by Claude Code Patch Reviewer