Claude review: drm/msm: fbdev: Use a DRM client buffer

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

Patch Review

**Status: Bug in error handling.**

The core conversion to use `drm_client_buffer_create()` and `drm_client_buffer_delete()` is correct in concept. The success path reference counting is sound:

1. `msm_gem_new()` → refcount = 1
2. `drm_gem_handle_create(file, bo, &handle)` → refcount = 2
3. `drm_client_buffer_create()` (internally looks up handle, fb takes ref) → refcount = 3
4. `drm_gem_handle_delete(file, handle)` → refcount = 2
5. `drm_gem_object_put(bo)` → refcount = 1 (only the framebuffer holds a reference)

The destroy path in `msm_fbdev_fb_destroy()` is also correct: `msm_gem_put_vaddr()` releases the mapping, then `drm_client_buffer_delete()` removes the framebuffer (dropping the last GEM reference).

**Bug:** The error goto when `msm_gem_get_vaddr()` fails is wrong:

```c
fbi->screen_buffer = msm_gem_get_vaddr(bo);
if (IS_ERR(fbi->screen_buffer)) {
    ret = PTR_ERR(fbi->screen_buffer);
    goto err_msm_gem_put_vaddr;  // BUG: vaddr was never acquired
}
```

Looking at `get_vaddr()` in `msm_gem.c:708`, when it fails it cleans up internally (decrements `vmap_count`, unpins). Calling `msm_gem_put_vaddr()` after a failed `msm_gem_get_vaddr()` would decrement `vmap_count` below its correct value, triggering:

```c
GEM_WARN_ON(msm_obj->vmap_count < 1);  // msm_gem.c:782
```

**The fix:** This goto should be `goto err_drm_client_buffer_delete;` instead.

---
Generated by Claude Code Patch Reviewer