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: Add support for client indicating support for luminance
Date: Thu, 04 Jun 2026 14:54:31 +1000
Message-ID: <review-patch4-20260531114908.1693426-5-superm1@kernel.org>
In-Reply-To: <20260531114908.1693426-5-superm1@kernel.org>
References: <20260531114908.1693426-1-superm1@kernel.org> <20260531114908.1693426-5-superm1@kernel.org>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Patch Review

**Issue: Modifying connector->state without holding atomic lock**

```c
+	if (connector->state)
+		connector->state->luminance =3D set;
```

This is in `__drm_backlight_real_changed`, called under the spinlock. Writi=
ng to `connector->state->luminance` without holding the atomic modeset lock=
 is a race with any concurrent atomic commit that might be swapping connect=
or states.

**Concern: DPMS handling in drm_atomic_connector_commit_dpms**

The patch modifies this function significantly, but the base code has chang=
ed =E2=80=94 upstream uses `struct drm_atomic_commit *state` while the patc=
h shows `struct drm_atomic_state *state`. This indicates a base mismatch th=
at will need rebasing.

The DPMS backlight coordination logic is complex with both legacy and atomi=
c paths:
```c
+	crtc =3D connector->state ? connector->state->crtc : NULL;
+
+	if (old_mode !=3D DRM_MODE_DPMS_OFF && mode =3D=3D DRM_MODE_DPMS_OFF) {
+		if (crtc)
+			drm_atomic_crtc_set_backlight(crtc, false);
```

This null-checks `connector->state` (good, fixing a potential NULL deref in=
 the original), but the original code unconditionally did `crtc =3D connect=
or->state->crtc`. So this is also a bugfix, but it should be a separate pat=
ch.

**Issue: `drm_backlight_set_luminance` WARN_ON on failure then fallback**

```c
+		int rc =3D backlight_set_brightness(bd, set, BACKLIGHT_UPDATE_DRM);
+		WARN_ON(rc);
+		if (rc)
+			backlight_set_brightness(bd, max, BACKLIGHT_UPDATE_DRM);
```

`WARN_ON` in normal operation is too aggressive. If the hardware is busy or=
 the panel is off, the brightness set can legitimately fail. Using `WARN_ON=
` will spam dmesg and could be flagged by CI. The fallback to max brightnes=
s on failure is also questionable =E2=80=94 if setting `set` failed, why wo=
uld setting `max` succeed? And setting max on failure seems wrong =E2=80=94=
 the user asked for a specific brightness.

**Issue: drm_takeover atomic vs spinlock**

`drm_takeover` is an `atomic_t` on `backlight_device`, modified under `drm_=
backlight_lock` spinlock:
```c
+	if (b->link)
+		atomic_inc(&b->link->drm_takeover);
```

But it's read without the spinlock in `brightness_store`:
```c
+	if (atomic_read(&bd->drm_takeover) > 0)
+		return -EBUSY;
```

This is fine for the intended purpose (advisory check, TOCTOU is acceptable=
 here), but the use of both a spinlock and atomics is redundant =E2=80=94 i=
f the atomic is sufficient for the read side, the spinlock protection on th=
e write side is unnecessary overhead. Pick one synchronization mechanism.

**Leftover text in changelog**: Line `f-luminance` appears to be a stray fr=
agment in the commit message changelog area.

---
Generated by Claude Code Patch Reviewer