Claude review: DRM: Add support for client indicating support for luminance

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

Patch Review

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

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

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

**Concern: DPMS handling in drm_atomic_connector_commit_dpms**

The patch modifies this function significantly, but the base code has changed — upstream uses `struct drm_atomic_commit *state` while the patch shows `struct drm_atomic_state *state`. This indicates a base mismatch that will need rebasing.

The DPMS backlight coordination logic is complex with both legacy and atomic paths:
```c
+	crtc = connector->state ? connector->state->crtc : NULL;
+
+	if (old_mode != DRM_MODE_DPMS_OFF && mode == 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 = connector->state->crtc`. So this is also a bugfix, but it should be a separate patch.

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

```c
+		int rc = 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 brightness on failure is also questionable — if setting `set` failed, why would setting `max` succeed? And setting max on failure seems wrong — 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 — if the atomic is sufficient for the read side, the spinlock protection on the write side is unnecessary overhead. Pick one synchronization mechanism.

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

---
Generated by Claude Code Patch Reviewer