DF-4126 — Inverted error check at rv6xx_dpm_init:1957-1969 — ATOM-computed SPLL/MPLL reference divider used only when radeon_atom_get_clock_dividers FAILS, default used on success

• File: sys/dev/drm/radeon/rv6xx_dpm.c
• Lines: 1957-1969 Severity: Low Confidence: certain
• Status: inconclusive (impact: none) — hardware-gated crafted-VBIOS/firmware threat model; source-level certainty, no GPU in guest.

Summary

Both clock-divider probes in rv6xx_dpm_init() test if (ret) where every sibling dispatch tests success: rv6xx_dpm.c:1957-1962 (SPLL): ret = radeon_atom_get_clock_dividers(..., &dividers); if (ret) pi->spll_ref_div = dividers.ref_div + 1; <- taken on FAILURE else pi->spll_ref_div = R600_REFERENCEDIVIDER_DFLT; rv6xx_dpm.c:1964-1969 (MPLL): same inverted shape for mpll_ref_div. On SUCCESS the ATOM-computed divider is discarded and the default (4) is used; on FAILURE the callee-zeroed dividers are consumed (radeon_atombios.c:2838 memsets dividers), yielding ref_div+1 = 1. The value is programmed into the PLL: r600_engine_clock_entry_set_reference_divider( step, pi->spll_ref_div - 1) at rv6xx_dpm.c:187-188 (programs 0 on the failure branch) and folds into the feedback divider at :184 — wrong SPLL/MPLL programming (display/GPU instability) from VBIOS-dependent atom behavior. rv6xx instance of the DF-3976/DF-4119 family (last member).

Reproduce

No runnable kernel PoC: requires RV6xx/i915 hardware. See VERDICT.md for the full line-by-line source trace and fix.diff for the validated patch.

Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64

DF-4126 verdict — Inverted error check at rv6xx_dpm_init:1957-1969 — ATOM-computed SPLL/MPLL reference divider used only when radeon_atom_get_clock_dividers FAILS, default used on success

Reproduced? — inconclusive (none)

Source-certain logic inversion (every sibling dispatch uses if (!ret); cypress DF-4119 and btc DF-3976 are the same line-shape). Hardware-gated, no observable impact without RV6xx silicon; the deterministic consequences are: success path ignores ATOM dividers (uses 4), failure path consumes the callee-zeroed struct and programs ref divider 0. Not memory-unsafe — radeon_atombios.c:2838 memsets the struct, so unlike the cypress wording there is no uninitialized read here.

Root cause (path:line)

Both clock-divider probes in rv6xx_dpm_init() test if (ret) where every sibling dispatch tests success: rv6xx_dpm.c:1957-1962 (SPLL): ret = radeon_atom_get_clock_dividers(..., &dividers); if (ret) pi->spll_ref_div = dividers.ref_div + 1; <- taken on FAILURE else pi->spll_ref_div = R600_REFERENCEDIVIDER_DFLT; rv6xx_dpm.c:1964-1969 (MPLL): same inverted shape for mpll_ref_div. On SUCCESS the ATOM-computed divider is discarded and the default (4) is used; on FAILURE the callee-zeroed dividers are consumed (radeon_atombios.c:2838 memsets dividers), yielding ref_div+1 = 1. The value is programmed into the PLL: r600_engine_clock_entry_set_reference_divider( step, pi->spll_ref_div - 1) at rv6xx_dpm.c:187-188 (programs 0 on the failure branch) and folds into the feedback divider at :184 — wrong SPLL/MPLL programming (display/GPU instability) from VBIOS-dependent atom behavior. rv6xx instance of the DF-3976/DF-4119 family (last member).

Chain

radeon_atom_get_clock_dividers fails/succeeds -> inverted branch picks default on success, zeroed ref_div+1=1 on failure -> pi->spll_ref_div/mpll_ref_div wrong -> rv6xx_output_stepping:184-190 programs wrong PLL ref/fb dividers

Kernel refs

• sys/dev/drm/radeon/rv6xx_dpm.c:1957
• sys/dev/drm/radeon/rv6xx_dpm.c:1964
• sys/dev/drm/radeon/rv6xx_dpm.c:184
• sys/dev/drm/radeon/rv6xx_dpm.c:187
• sys/dev/drm/radeon/radeon_atombios.c:2838

Fix

Two-character fix per branch (matches every sibling dispatch).

fix.diff applies cleanly against the read-only sys/ tree (2-file for DF-4125; note the radeon_pm.c hunk also needs dpm_failed_unlock: mutex_unlock(&rdev->pm.mutex); added to the existing dpm_failed label path — spelled out here since the label does not exist in the unfixed tree). Kernel-level fix validation is not possible on this guest (no i915/RV6xx devices; the drivers never attach in QEMU).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.