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

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

Patch Review

**Status: Good**

This is the core change. The old flow created a framebuffer directly via `exynos_drm_framebuffer_init()`. The new flow:

1. Creates a GEM handle via `drm_gem_handle_create()`
2. Creates a client buffer via `drm_client_buffer_create()` (which internally does ADDFB2)
3. Cleans up the handle and drops the initial GEM reference

The reference counting is correct:
```c
/* The handle is only needed for creating the framebuffer. */
drm_gem_handle_delete(file, handle);

/* The framebuffer still holds a reference on the GEM object. */
drm_gem_object_put(obj);
```

After these two lines, the GEM object survives with exactly one reference held by the framebuffer created inside `drm_client_buffer_create()`. The `exynos_gem->kvaddr` read happens before `drm_gem_object_put()`, so we're dereferencing the pointer while still holding our own reference. The stored `kvaddr` value remains valid as long as the framebuffer exists.

The cleanup in `exynos_drm_fb_destroy` is simplified:
```c
-	drm_framebuffer_remove(fb);
+	drm_client_buffer_delete(fb_helper->buffer);
```

`drm_client_buffer_delete()` handles framebuffer removal and releasing the GEM reference, which is the right cleanup for the client buffer path.

The error paths correctly unwind in reverse order:
```c
err_drm_gem_handle_delete:
    drm_gem_handle_delete(file, handle);
err_drm_gem_object_put:
    drm_gem_object_put(obj);
```

Note: the old error path used `exynos_drm_gem_destroy(exynos_gem)` while the new one uses `drm_gem_object_put(obj)`. Since `exynos_drm_gem_create()` returns the object with refcount=1, `drm_gem_object_put` is the correct generic way to release it (it will call the destroy callback when refcount drops to 0). This is a clean improvement.

No concerns.

---

---
Generated by Claude Code Patch Reviewer