Re: [PATCH v5] drm/bridge: dw-hdmi-qp: Guard clear_audio_infoframe when PHY is down

[Igor Paunovic <royalnet026@gmail.com>]

Hi Frank,

Thank you for sending v5 so quickly.

I tested it on an Orange Pi 5 Plus (RK3588) against the exact case I
reported in [1]. v5 applied cleanly to my 7.2.0-rc7 based tree with no
context fixup, which v4 still needed here.

Reproducer, unchanged from [1]: the compositor turns the HDMI sink off
(so tmds_char_rate is 0 and the PHY is down), then plughw:hdmi1,0 is
opened and closed. Before, that took the machine down on close, in
dw_hdmi_qp_bridge_clear_audio_infoframe() -> regmap_update_bits_base()
-> _regmap_read() -> regmap_mmio_read32le(), either as a synchronous
external abort in the closing task or as an asynchronous SError panic.
The task died with interrupts disabled, so the codec lock stayed held
and every later open of that PCM hung in D state until reboot.

With v5 applied, three consecutive open/close cycles in that state all
behave identically: prepare fails with -ENODEV as before (3 x "ASoC
error (-19) at snd_soc_dai_prepare()"), no external abort, no SError,
the shutdown path completes, and the PCM can be opened again afterwards.

I also confirmed with ftrace that the guard is what stops it, rather than
the path simply not being reached. Tracing
dw_hdmi_qp_bridge_clear_audio_infoframe with function_graph:

  - sink off (tmds_char_rate == 0): the function is entered and returns
    as a leaf, 2.9 us, with no calls inside it at all.

  - sink on, as a positive control: the same function shows
    regmap_update_bits_base() -> _regmap_update_bits() -> _regmap_read()
    / _regmap_write() nested inside - the same frames the crash walked
    through - so the tracer does see the body, and "empty" in the first
    case really is the tmds_char_rate check taking effect.

Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus (RK3588)

Two notes, so this is not read as more than it is.

First, what I exercised is the sequential case: the display is already
off before the audio device is closed. I did not try to hit the narrow
window the automated review raised in this thread, where the atomic
disable lands between the tmds_char_rate check and the register access,
so my test says nothing about that race either way.

Second, for whoever picks this up: Detlev Casanova's patch [2] covers
the other half of the same problem on this hardware - the enable/prepare
side returning -EOPNOTSUPP when there is no link - and has three
Tested-by tags. The two are complementary here. His cuts the case where
the PCM is opened while the sink is already off; yours covers the case
where the PCM is already open and the output goes away underneath it.
Taking only one of them still leaves a way to reach the crash. With both
applied together on this board the path is quiet and the -19 messages
are gone as well.

[1] https://lore.kernel.org/all/20260907153000.hdmiqp-audio-1-royalnet026@gmail.com/
[2] https://lore.kernel.org/all/20260519-fix-hdmi-audio-warnings-v1-1-9608966c993f@collabora.com/

Igor