# DF-5206 — trinity_acquire_mutex() cannot fail: silently proceeds without the SMC mutex on timeout

File: `sys/dev/drm/radeon/trinity_smc.c:112-122` (+ all call sites in `trinity_dpm.c`)
Severity: Info — hardware-reliability fail-open, unique to Trinity in the radeon
SMC family (kv/si/ci/sumo have no equivalent void mutex-grant wait).

## The defect

`trinity_acquire_mutex()` requests the SMC firmware mutex by writing 1 to
`SMC_INT_REQ` (register `0x220`, trinityd.h:167) and polls for the grant:

```c
void trinity_acquire_mutex(struct radeon_device *rdev)   /* :112 — VOID */
{
	int i;

	WREG32(SMC_INT_REQ, 1);                            /* :116 */
	for (i = 0; i < rdev->usec_timeout; i++) {         /* :117 — up to 100 ms */
		if ((RREG32(SMC_INT_REQ) & 0xffff) == 1)       /* :118 */
			break;                                     /* grant */
		udelay(1);
	}
}                                                        /* :122 — timeout: silent return */
```

If the SMC firmware never grants the mutex (busy, wedged, or in a failure
state), the function **returns anyway after the 100 ms poll**, without the
mutex and without any way to tell the caller: the return type is `void`, so the
failure is unreportable by construction. Every caller then programs SMC
registers as if exclusivity vs the SMC firmware were held:

* `trinity_dpm_enable_bapm`   — trinity_dpm.c:1099
* `trinity_dpm_enable`        — trinity_dpm.c:1109
* `trinity_dpm_late_enable`   — trinity_dpm.c:1138
* `trinity_dpm_disable`       — trinity_dpm.c:1158
* `trinity_dpm_set_power_state` — trinity_dpm.c:1258
* `trinity_dpm_setup_asic`    — trinity_dpm.c:1288
* (a 7th site at :1300 is inside `#if 0` — dead code)

This mutex exists precisely to serialize the host driver against the SMC
firmware's own accesses during DPM reprogramming; proceeding without it lets
host register sequences interleave with SMC-internal ones → corrupted SMC
register programs (clock/voltage/power-gating misprogramming). Reliability
defect; no memory-safety primitive and no attacker-controlled input.

## Why untested (see VERDICT.md)

Requires AMD Trinity hardware with an SMC that refuses the mutex grant. The
audit QEMU guest has no radeon GPU; Info-class finding exempt from guest
verification per the audit contract. `fix.diff` (API change: `int` return +
`-ETIME`, all live call sites updated to bail out) is authored and
`git apply --check`-verified, not hardware-validated.

## Fix

`fix.diff` — `trinity_acquire_mutex()` returns `int` (`0` on grant,
`-ETIME` after backing off the request), prototype in `trinity_dpm.h` updated,
and all six live call sites in `trinity_dpm.c` check the result and bail out.