Claude review: backlight: add kernel-internal backlight API

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

Patch Review

**Concern: Double notification in backlight_set_brightness**

`backlight_set_brightness` calls `backlight_update_status(bd)` and then `backlight_generate_event()`. But in patch 3, `backlight_update_status` is modified to also call `backlight_notify_brightness()`. This means a single `backlight_set_brightness` call will:
1. Call `backlight_update_status` → which calls `backlight_notify_brightness` (notifier chain)
2. Then call `backlight_generate_event` (uevent)
3. The notifier from step 1 fires `__drm_backlight_real_changed` which is supposed to update the DRM property

The `backlight_generate_event` call here is arguably correct (it sends a uevent), but the interaction with the notifier added in patch 3 creates a loop risk: DRM sets brightness → `backlight_set_brightness` → `backlight_update_status` → `backlight_notify_brightness` → DRM notifier → `__drm_backlight_real_changed`. The `__drm_backlight_real_changed` function updates `connector->state->luminance` under spinlock, which should be safe, but it's worth verifying there's no re-entrant path.

**Concern: ops_lock held across backlight_generate_event**

```c
+	guard(mutex)(&bd->ops_lock);
+	if (bd->ops) {
+		if (value > bd->props.max_brightness)
+			return -EINVAL;
+		bd->props.brightness = value;
+		rc = backlight_update_status(bd);
+	}
+	if (rc == 0)
+		backlight_generate_event(bd, reason);
```

`backlight_generate_event` calls `kobject_uevent_env` which can sleep and allocate. It's called with `ops_lock` held (via `guard`). While `ops_lock` is a mutex so sleeping is OK, holding it longer than necessary across a uevent broadcast isn't ideal. But it's not a correctness bug.

**Minor**: `backlight_set_brightness` sends a uevent even when `bd->ops` is NULL (rc stays 0 in that case). Should it return early if ops is NULL?

---
Generated by Claude Code Patch Reviewer