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

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

Overall Series Review

Subject: drm/bridge: dw-hdmi-qp: Guard clear_audio_infoframe when PHY is down
Author: Frank Zhang <rmxpzlb@gmail.com>
Patches: 1
Reviewed: 2026-05-16T13:45:35.779160

---

This is a single-patch bug fix for a kernel panic (Asynchronous SError Interrupt) triggered when pipewire closes an HDMI audio device after the display pipeline has already been disabled. The race is: `atomic_disable()` sets `tmds_char_rate = 0` and powers down the PHY, then pipewire's PCM release path calls `dw_hdmi_qp_bridge_clear_audio_infoframe()` which performs a regmap write to hardware that is no longer clocked, causing an SError.

The fix is reasonable and addresses a real crash. The approach of guarding `clear_audio_infoframe` with a `tmds_char_rate` check follows the existing pattern already used in `dw_hdmi_qp_audio_enable()` (line 472) and `dw_hdmi_qp_audio_disable()` (line 531). The decoupling of write from clear avoids adding the guard in the write path where it would be unnecessary (write is only called when the PHY is active).

One concern: the other `clear_*_infoframe` functions (`clear_avi_infoframe`, `clear_hdmi_infoframe`, `clear_hdr_drm_infoframe`, `clear_spd_infoframe`) do **not** have the same `tmds_char_rate` guard. If any of those can also be called after PHY teardown, they would have the same bug. This patch only fixes the audio path because that's where the crash was observed, but it may be worth considering whether the same race exists for other infoframes. That said, for a targeted stable-backport fix, limiting scope to the observed crash is pragmatic.

**Verdict: The patch looks correct for the stated problem. Recommend accepting with minor comments.**

---

---
Generated by Claude Code Patch Reviewer