Claude review: drm/atomic: only add colorop state from active color pipeline

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

Patch Review

**Assessment: Good, minor nit**

This patch changes `drm_atomic_add_affected_colorops()` to take a `drm_plane_state *` instead of `drm_atomic_state *`, and walks only the active `color_pipeline` linked list instead of iterating all colorops on the device and filtering by plane.

The key behavioral change is sound — previously `drm_for_each_colorop(colorop, plane->dev)` iterated *all* colorops across *all* planes on the device, filtering by `colorop->plane != plane`. Now it walks only the active pipeline chain:

```c
for (colorop = plane_state->color_pipeline;
     colorop;
     colorop = colorop->next) {
```

This is both more efficient and more correct (no states get created for colorops from inactive pipelines).

The NULL guard at the top is clean:
```c
if (!plane_state || !plane_state->color_pipeline)
    return 0;
```

The callers in `drm_atomic_add_affected_planes()` and `drm_atomic_helper_duplicate_state()` are updated to remove the now-redundant `if (plane_state->color_pipeline)` check and pass `plane_state` instead of `state`.

**Nit**: The kernel-doc parameter name changed from `@state` to `@plane_state`, but the declaration in `drm_atomic.h` still uses the name `state`:
```c
drm_atomic_add_affected_colorops(struct drm_plane_state *state,
```
This is technically valid C, but calling a `drm_plane_state *` parameter "`state`" is confusing since "state" in the DRM atomic world typically refers to `drm_atomic_state`. Consider naming it `plane_state` in the header declaration to match the implementation.

The removal of `WARN_ON(!drm_atomic_get_new_plane_state(state, plane))` makes sense since the function now receives the plane_state directly.

---
Generated by Claude Code Patch Reviewer