Claude review: drm/amd/display: Avoid using zero AC/DC brightness levels

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

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 firmware values to be used. This is a conservative choice.

**Concern — should this be `||` instead of `&&`?** Consider a system 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 relevant one (based on `power_supply_is_system_supplied()`) might be perfectly valid. An alternative approach would be to only check the value actually being used:

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

However, the current approach is simpler and more conservative — if the firmware is giving bogus zeros for one field, the other field may be suspect 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.brightness` and `props.max_brightness` to `MAX_BACKLIGHT_LEVEL`. Previously this only happened when `get_brightness_range()` failed (i.e., `caps` was NULL). 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 — the backlight 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 behavioral change worth noting: user-space will see a different `max_brightness` 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 correct; there's no sign issue. The values come from ACPI firmware (`amdgpu_acpi.c:400-401`) and represent percentages (0-100).

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

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

---
Generated by Claude Code Patch Reviewer