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/amd/display: Avoid using zero AC/DC brightness levels
Date: Thu, 28 May 2026 12:44:13 +1000
Message-ID: <review-patch1-20260526210048.1162477-1-edson.drosdeck@gmail.com>
In-Reply-To: <20260526210048.1162477-1-edson.drosdeck@gmail.com>
References: <20260526210048.1162477-1-edson.drosdeck@gmail.com> <20260526210048.1162477-1-edson.drosdeck@gmail.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

**Correctness: Generally good, with one behavioral concern.**

The added checks at `amdgpu_dm.c:5509-5511`:
```c
if (get_brightness_range(caps, &min, &max) &&
    caps->ac_level > 0 &&
    caps->dc_level > 0) {
```

This requires **both** `ac_level` and `dc_level` to be non-zero for the fir=
mware values to be used. This is a conservative choice.

**Concern =E2=80=94 should this be `||` instead of `&&`?** Consider a syste=
m where `ac_level` is valid (say 80) but `dc_level` is zero, or vice versa.=
 With this patch, both firmware values are discarded even though the releva=
nt one (based on `power_supply_is_system_supplied()`) might be perfectly va=
lid. An alternative approach would be to only check the value actually bein=
g used:

```c
if (get_brightness_range(caps, &min, &max)) {
    if (power_supply_is_system_supplied() > 0 && caps->ac_level > 0)
        props.brightness =3D DIV_ROUND_CLOSEST(...ac_level...);
    else if (caps->dc_level > 0)
        props.brightness =3D DIV_ROUND_CLOSEST(...dc_level...);
    else
        /* fallback */
```

However, the current approach is simpler and more conservative =E2=80=94 if=
 the firmware is giving bogus zeros for one field, the other field may be s=
uspect too. This is a reasonable engineering judgment.

**Fallback path sets `max_brightness` to `MAX_BACKLIGHT_LEVEL`:** When the =
new guard rejects zero levels, the fallback at line 5521 sets both `props.b=
rightness` and `props.max_brightness` to `MAX_BACKLIGHT_LEVEL`. Previously =
this only happened when `get_brightness_range()` failed (i.e., `caps` was N=
ULL). Now it also fires when caps exist but have zero AC/DC levels. In this=
 case the firmware's min/max range is valid but unused =E2=80=94 the backli=
ght gets registered with `MAX_BACKLIGHT_LEVEL` as its range instead of the =
firmware-reported range. This seems acceptable as a safe default but is a b=
ehavioral change worth noting: user-space will see a different `max_brightn=
ess` on these affected systems than it would if only the initial brightness=
 were corrected.

**`ac_level` and `dc_level` are `u8` (unsigned):** The `> 0` checks are cor=
rect; there's no sign issue. The values come from ACPI firmware (`amdgpu_ac=
pi.c:400-401`) and represent percentages (0-100).

**Commit message nits:**
- Missing period at the end of "Only use the firmware brightness levels whe=
n both AC and DC values are non-zero" =E2=80=94 minor style issue.
- The commit message could benefit from a `Fixes:` tag referencing the comm=
it that introduced this brightness initialization logic, to help stable ker=
nel backporting.
- No `Cc: stable@vger.kernel.org` tag =E2=80=94 if this is intended as a bu=
g fix for existing systems, it may be worth adding one.

**Overall:** The patch is simple, correct for the stated problem, and low-r=
isk. Recommend adding a `Fixes:` tag and considering whether the fallback s=
hould preserve the firmware's `max_brightness` range even when it discards =
the initial brightness value.

---
Generated by Claude Code Patch Reviewer