From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/connector: Add a 'link bpc' property
Date: Tue, 31 Mar 2026 17:31:19 +1000
Message-ID: <review-patch1-20260330-link-bpc-v6-1-ff124af93e48@collabora.com>
In-Reply-To: <20260330-link-bpc-v6-1-ff124af93e48@collabora.com>
References: <20260330-link-bpc-v6-0-ff124af93e48@collabora.com> <20260330-link-bpc-v6-1-ff124af93e48@collabora.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Patch Review

**Overall:** Solid infrastructure patch. The property creation, update mech=
anism, uevent firing, and documentation are all reasonable.

**Issue 1 (minor): `clamp()` type mismatch in `drm_connector_update_link_bp=
c_property`**

```c
u8 bpc =3D clamp(state->link_bpc, 8, state->max_bpc);
```

`state->link_bpc` and `state->max_bpc` are both `u8`, but the literal `8` i=
s an `int`. The kernel's `clamp()` macro with `__builtin_choose_expr` type =
checking may warn or misbehave with mixed types depending on the kernel ver=
sion. Consider using `clamp_t(u8, state->link_bpc, 8, state->max_bpc)` for =
explicit type safety.

**Issue 2 (medium): link_bpc update fires uevent before hw commit**

In `commit_tail()`:
```c
drm_atomic_helper_wait_for_dependencies(state);

for_each_oldnew_connector_in_state(state, connector, old_conn_state,
                                   new_conn_state, i) {
    if (old_conn_state->link_bpc !=3D new_conn_state->link_bpc)
        drm_connector_update_link_bpc_property(connector,
                                               new_conn_state);
}
```

The property update and uevent fire **before** `funcs->atomic_commit_tail()=
` is called (which does the actual hw commit). This means userspace receive=
s the notification that link bpc changed before the hardware has actually b=
een programmed. Arguably this should happen after `atomic_commit_tail` retu=
rns (or at least after `commit_hw_done`). Is there a deliberate reason for =
this ordering? It would be more correct to place this after the tail functi=
on call, similar to how other post-commit work is done.

**Issue 3 (nit): Extra space in doc comment**

```c
 * @max_bpc: specify the upper limit, matching  that of 'max bpc' property
```

Double space before "that".

**Issue 4 (minor): unconditional uevent in update function**

`drm_connector_update_link_bpc_property()` always fires a uevent even thoug=
h the caller in `commit_tail` already checked that the value changed. This =
is fine from a correctness standpoint since the caller does the filtering, =
but the function itself has no guard =E2=80=94 if called outside `commit_ta=
il` without a prior check it would fire spurious uevents. The function name=
 suggests "update" which implies a change, so this is acceptable, but docum=
enting the expectation that callers check for changes would be good.

**Design observation:** The initial property value is set to `max_bpc` in `=
drm_connector_attach_link_bpc_property()`:
```c
drm_object_attach_property(&connector->base, prop, max_bpc);
```

This means before the first commit, userspace sees `link_bpc =3D=3D max_bpc=
`, which is optimistic but reasonable as a default. Worth noting in the doc=
umentation.

---
Generated by Claude Code Patch Reviewer