Claude review: drm/connector: Add a 'link bpc' property

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

Patch Review

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

**Issue 1 (minor): `clamp()` type mismatch in `drm_connector_update_link_bpc_property`**

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

`state->link_bpc` and `state->max_bpc` are both `u8`, but the literal `8` is an `int`. The kernel's `clamp()` macro with `__builtin_choose_expr` type checking may warn or misbehave with mixed types depending on the kernel version. 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 != 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 receives the notification that link bpc changed before the hardware has actually been programmed. Arguably this should happen after `atomic_commit_tail` returns (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 function 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 though 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 — if called outside `commit_tail` without a prior check it would fire spurious uevents. The function name suggests "update" which implies a change, so this is acceptable, but documenting 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 == max_bpc`, which is optimistic but reasonable as a default. Worth noting in the documentation.

---
Generated by Claude Code Patch Reviewer