From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/atomic: track individual colorop updates
Date: Wed, 25 Mar 2026 07:51:14 +1000 [thread overview]
Message-ID: <review-patch1-20260323131942.494217-2-mwen@igalia.com> (raw)
In-Reply-To: <20260323131942.494217-2-mwen@igalia.com>
Patch Review
**Overall:** Solid patch. The approach of threading a `bool *replaced` through the colorop property-set path and using it to conditionally set `plane_state->color_mgmt_changed` is clean and consistent.
**Observations:**
1. **`drm_atomic_set_colorop_for_plane` return value change** (lines 213-233): Changing from `void` to `bool` and adding the early-return short-circuit is good. The usage at line 241:
```c
state->color_mgmt_changed |= drm_atomic_set_colorop_for_plane(state, colorop);
```
Correctly uses `|=` to avoid clearing a previously-set flag. Good.
2. **Interpolation properties intentionally not tracked** (lines 282, 295): The `lut1d_interpolation` and `lut3d_interpolation` properties are set directly on the `colorop` object (not `state`) and don't set `*replaced`. The cover letter mentions these are read-only properties and intentionally excluded. This is correct - they describe hardware capabilities rather than userspace-settable state.
3. **`replaced` naming convention**: The `bool *replaced` out-parameter is functional but the name is slightly misleading for scalar properties like `bypass` or `multiplier` where nothing is being "replaced" (that term fits blob properties better). Something like `changed` would be more natural. Minor style nit, not worth a respin.
4. **Plane state fetch on colorop change** (lines 324-329): In `drm_atomic_set_property`, when a colorop value changes, the code fetches the plane state via `drm_atomic_get_plane_state()`. This is correct - it ensures the plane is part of the atomic commit and its state is properly tracked. The error handling with `PTR_ERR` is also correct.
5. **`#include <linux/types.h>`** (line 341): Added to provide `bool` for the header. This is the right fix for the build issue the kernel bot reported on MSM.
6. **Missing tracking for `drm_atomic_colorop_set_property` unknown property path** (lines 302-306): If the property is unknown, the function returns `-EINVAL` and `*replaced` remains `false`. The caller at line 321 checks `if (ret || !replaced)` and breaks. This correctly avoids setting `color_mgmt_changed` on error. Good.
7. **Thread safety consideration**: The `replaced` variable is stack-local in `drm_atomic_set_property` (line 310), so no concurrency concerns. Fine.
---
Generated by Claude Code Patch Reviewer
next prev parent reply other threads:[~2026-03-24 21:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 13:15 [PATCH v2 0/2] drm/atomic: track colorop changes of a given plane Melissa Wen
2026-03-23 13:15 ` [PATCH v2 1/2] drm/atomic: track individual colorop updates Melissa Wen
2026-03-24 21:51 ` Claude Code Review Bot [this message]
2026-03-23 13:15 ` [PATCH v2 2/2] drm/amd/display: use plane color_mgmt_changed to track colorop changes Melissa Wen
2026-03-24 21:51 ` Claude review: " Claude Code Review Bot
2026-03-24 21:51 ` Claude review: drm/atomic: track colorop changes of a given plane Claude Code Review Bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=review-patch1-20260323131942.494217-2-mwen@igalia.com \
--to=claude-review@example.com \
--cc=dri-devel-reviews@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox