Claude review: drm/bridge: dw-hdmi-qp: Guard clear_audio_infoframe when PHY is down

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

Patch Review

**Commit message:** Well-written. Includes the panic trace, clear root cause analysis, and describes the three logical changes (guard, decouple, balance AMD bit). The Fixes tag and Cc: stable are appropriate.

**Change 1 — Guard in `clear_audio_infoframe` (lines 889-893):**

```c
if (hdmi->tmds_char_rate)
	dw_hdmi_qp_mod(hdmi, 0,
		       PKTSCHED_ACR_TX_EN | PKTSCHED_AMD_TX_EN |
		       PKTSCHED_AUDS_TX_EN | PKTSCHED_AUDI_TX_EN,
		       PKTSCHED_PKT_EN);
```

This is the core fix. When `tmds_char_rate == 0`, the PHY is down and register access is unsafe, so we skip it. The function still returns 0, which is fine — the framework doesn't act on error returns from `clear_infoframe` callbacks, and there's nothing useful to do when the PHY is already off.

No locking concern: `tmds_char_rate` is set to 0 in `atomic_disable` and the audio shutdown path is the only late caller, so reading it without a lock is acceptable for this guard-check pattern (a stale non-zero read would just do a harmless register write before the PHY goes down).

**Change 2 — Decouple `write_audio_infoframe` from `clear_audio_infoframe` (lines 992-995):**

```c
dw_hdmi_qp_mod(hdmi, 0,
	       PKTSCHED_ACR_TX_EN | PKTSCHED_AMD_TX_EN |
	       PKTSCHED_AUDS_TX_EN | PKTSCHED_AUDI_TX_EN,
	       PKTSCHED_PKT_EN);
```

Previously `write_audio_infoframe` called `clear_audio_infoframe` to disable packets before re-programming them. Now it inlines the `dw_hdmi_qp_mod` call directly, avoiding the `tmds_char_rate` guard that would be incorrect in the write path (where the PHY **is** up). This is the right design — the write path is only called when audio is being configured, so the PHY must be active. All other `write_*_infoframe` functions (AVI, HDMI, HDR_DRM, SPD) also call their corresponding clear functions directly without a guard, so this is consistent in spirit even though the implementation is now inlined rather than calling through.

**Change 3 — Adding `PKTSCHED_AMD_TX_EN` to the clear mask:**

The original `clear_audio_infoframe` cleared `ACR`, `AUDS`, and `AUDI` but not `AMD`. However, `write_audio_infoframe` enables all four (`ACR`, `AUDI`, `AMD` at line 1014, plus `AUDS` at line 1019). The clear path was missing the `AMD` disable, meaning repeated write/clear cycles would leave `PKTSCHED_AMD_TX_EN` set. Adding it to both the clear function and the inline clear in write restores proper enable/disable balance. This is a genuine secondary bug fix.

**Minor observations:**

1. **Consistency with other clear functions:** As noted above, `clear_avi_infoframe`, `clear_hdmi_infoframe`, `clear_hdr_drm_infoframe`, and `clear_spd_infoframe` don't guard on `tmds_char_rate`. If those can ever be called after PHY shutdown (e.g., through framework infoframe management during connector teardown), they would have the same crash. The author might want to investigate whether follow-up patches are needed there, though this is out of scope for the immediate crash fix.

2. **Race window:** There's a theoretical race where `atomic_disable` sets `tmds_char_rate = 0` and then disables the PHY, and between those two operations another CPU could read `tmds_char_rate != 0` and proceed with the register write. However, `tmds_char_rate` is set to 0 **before** `phy.ops->disable()` at lines 792-794, so the window is actually safe — the PHY is still up when the rate is zeroed. The truly dangerous case (PHY already down, rate not yet zeroed) cannot happen with the current ordering.

**Overall: Clean, well-scoped fix. The three changes are logically coherent and the commit message explains the rationale clearly. Recommend acceptance.**

---
Generated by Claude Code Patch Reviewer