Claude review: drm/atomic: don't set colorop properties of inactive color pipelines

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

Patch Review

**Purpose:** Rejects userspace attempts to set properties on colorops that are not part of the currently active pipeline.

**Review:**

The validation logic is correct — walk the active pipeline to verify the target colorop belongs to it:

```c
for (active_colorop = plane_state->color_pipeline;
     active_colorop;
     active_colorop = active_colorop->next) {
    if (active_colorop == colorop) {
        colorop_state = drm_atomic_get_colorop_state(state, colorop);
```

**Concern — UAPI behavior change:** This introduces a new `-EINVAL` error for a scenario that previously succeeded silently. If any existing userspace was setting properties on colorops not in the active pipeline (even if it was a no-op), this will now break it. The commit message should ideally note this is an intentional UAPI tightening and explain why it's safe (e.g., no known userspace does this, or the old behavior was always a bug).

**Concern — `goto err` label placement:** The new `err:` label sits just before `drm_property_change_valid_put`:

```c
+err:
 	drm_property_change_valid_put(prop, ref);
 	return ret;
```

This means when `drm_atomic_get_colorop_state` fails (returns IS_ERR), the code does `ret = PTR_ERR(colorop_state); goto err;` which correctly calls `drm_property_change_valid_put`. For the "not part of active pipeline" case, `ret = -EINVAL; goto err;` also correctly calls the put function. The error handling is correct.

**Minor observation:** Getting the plane state (`drm_atomic_get_plane_state`) for every colorop property set has a cost, but it's necessary for the pipeline walk and is already cheap if the state is already in the atomic state (common case).

---
Generated by Claude Code Patch Reviewer