Claude review: drm/colorop: make lut(1/3)d_interpolation props correctly behave as mutable

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

Patch Review

**Author:** Melissa Wen

This is the key data-model fix. It moves `lut1d_interpolation` and `lut3d_interpolation` from `struct drm_colorop` (the immutable base object) to `struct drm_colorop_state` (the per-atomic-commit mutable state).

**Changes reviewed:**

- **`include/drm/drm_colorop.h`**: Fields move from `drm_colorop` to `drm_colorop_state`. Clean move, correct types preserved.

- **`drm_atomic_uapi.c`**: `drm_atomic_colorop_set_property()` and `drm_atomic_colorop_get_property()` now read/write `state->lut1d_interpolation` / `state->lut3d_interpolation` instead of `colorop->lut1d_interpolation` / `colorop->lut3d_interpolation`. Correct.

- **`drm_atomic.c` (`drm_atomic_colorop_print_state`)**: Debug printing now reads from `state->` instead of `colorop->`. Correct.

- **`drm_colorop.c`**: The `__drm_colorop_state_reset()` function (called `__drm_colorop_state_init` in the mbox diff context lines — presumably renamed in the base tree) now initializes the interpolation fields from the property defaults via `drm_object_property_get_default_value()`. This follows the existing pattern for `curve_1d_type`. The `colorop->lut1d_interpolation = interpolation` assignments in `drm_plane_colorop_curve_1d_lut_init()` and `drm_plane_colorop_3dlut_init()` are correctly removed since the field no longer exists on `drm_colorop`.

**Potential concern:** The interpolation fields are unconditionally present on every `drm_colorop_state`, even for colorop types that don't use them (e.g., CTM_3X4, MULTIPLIER). This wastes a few bytes per state object but is harmless and consistent with how other fields like `data` are handled.

**Verdict:** Correct. No issues.

---

---
Generated by Claude Code Patch Reviewer