Re: [PATCH v4 3/7] drm/msm/hdmi_bridge: Correct poweroff/audio cleanup order in post_disable

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Concurrent lockless calls to `msm_hdmi_audio_update()` from ALSA/ASoC and DRM lead to unclocked MMIO accesses, hardware state corruption, and data races.
--

commit d1867d224f6fab10a2909a251c0566882d455741
Author: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Date:   Fri Sep 11 10:29:36 2026 +0000

    drm/msm/hdmi_bridge: Correct poweroff/audio cleanup order in post_disable

This commit reorders power_off() and msm_hdmi_audio_update() in
msm_hdmi_bridge_atomic_post_disable(). This ensures the HDMI block remains
powered on when msm_hdmi_audio_update() accesses hardware registers.

> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> --- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> @@ -339,10 +339,10 @@ static void msm_hdmi_bridge_atomic_post_disable(struct drm_bridge *bridge,
>  	msm_hdmi_phy_powerdown(phy);
>  
>  	if (hdmi->power_on) {
> -		power_off(bridge);
>  		hdmi->power_on = false;
>  		if (hdmi->connector->display_info.is_hdmi)
>  			msm_hdmi_audio_update(hdmi);

[Severity: High]
This isn't a bug introduced by this patch, but does this fully resolve the
unclocked MMIO accesses that can lead to hardware state corruption or bus
hangs?

While this correctly orders the power down sequence for the DRM bridge,
concurrent lockless calls to msm_hdmi_audio_update() can still happen from
ALSA/ASoC entry points while the display is powered off.

For example, a local user running an ALSA client can trigger this via the
prepare hook:

drivers/gpu/drm/msm/hdmi/hdmi_audio.c:msm_hdmi_bridge_audio_prepare() {
    ...
    return msm_hdmi_audio_update(hdmi);
}

Or during shutdown:

drivers/gpu/drm/msm/hdmi/hdmi_audio.c:msm_hdmi_bridge_audio_shutdown() {
    ...
    msm_hdmi_audio_update(hdmi);
}

Both of these ALSA hooks call msm_hdmi_audio_update() without acquiring
state_mutex or checking pm_runtime_get_sync(). If power_off() has already
disabled the clocks, the unclocked MMIO reads and writes in
msm_hdmi_audio_update():

drivers/gpu/drm/msm/hdmi/hdmi_audio.c:msm_hdmi_audio_update() {
    ...
    /* Read first before writing */
    acr_pkt_ctrl = hdmi_read(hdmi, REG_HDMI_ACR_PKT_CTRL);
    ...
}

can cause synchronous external aborts on ARM platforms resulting in a
kernel panic. Should these audio hooks be synchronized with the bridge
power state?

> +		power_off(bridge);
>  		msm_hdmi_phy_resource_disable(phy);
>  	}
>  	mutex_unlock(&hdmi->state_mutex);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911-drm-msm-hdmi-fixes-before-eliza-v4-0-87bdb9f1987f@oss.qualcomm.com?part=3