# DF-4768 — `psp_cmd_submit_buf` ignores `resp.status` when `ucode==NULL`: TMR/ASD load failures are reported as success

File: `sys/dev/drm/amd/amdgpu/amdgpu_psp.c` (pass 2)
Info-grade defense-in-depth finding; static (no AMD GPU on audit guest).

## Path

`psp_cmd_submit_buf()` (amdgpu_psp.c:118-150) checks the firmware's
response status only when a `ucode` argument was supplied:

```c
137:  /* the status field must be 0 after FW is loaded */
138:  if (ucode && psp->cmd_buf_mem->resp.status) {
139:      DRM_ERROR("failed loading with status (%d) and ucode id (%d)\n", ...);
141:      return -EINVAL;
```

The two callers that pass `ucode == NULL` are `psp_tmr_load()` (:193,
GFX_CMD_ID_SETUP_TMR — establishes the Trusted Memory Region) and
`psp_asd_load()` (:260, GFX_CMD_ID_LOAD_ASD). If PSP firmware rejects the
TMR setup or ASD load (`resp.status != 0`), the function still returns
`ret` (the ring-write status, typically 0), so:

- `psp_hw_start()` reports success and `psp_np_fw_load()` proceeds to
  load all security-sensitive ucode into a TMR the PSP never set up;
- the failure is silent — not even a log line.

Impact is firmware-robustness / security-state confusion (uCode loaded
without an established trusted region), not kernel memory corruption;
hence Info. No runtime PoC possible on this guest (amdgpu never
attaches).

## Fix

`fix.diff` — check `resp.status` unconditionally.