Re: [PATCH v3 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] ALSA audio callbacks execute locklessly and can run concurrently with the DRM modeset disable sequence or when the display is fully powered off, leading to unclocked MMIO access exceptions (kernel panics) and register corruption.
--

commit 7fe5c8b01a7d1a03dc085316a4205c3b77f6e3a8
Author: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

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

This commit corrects the poweroff and audio cleanup order in
msm_hdmi_bridge_atomic_post_disable() to ensure the block remains powered on
when msm_hdmi_audio_update() accesses registers.

> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> index db85400e574e4..1860605850c9b 100644
> --- 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);
> +		power_off(bridge);

[Severity: High]
This isn't a bug introduced by this patch, but does this still leave a race
window with concurrent lockless ALSA callbacks?

When userspace starts an audio stream on the HDMI audio PCM device, the ALSA
framework invokes msm_hdmi_bridge_audio_prepare() without acquiring
hdmi->state_mutex. This in turn calls msm_hdmi_audio_update(), which reads
hdmi->power_on locklessly:

drivers/gpu/drm/msm/hdmi/hdmi_audio.c:msm_hdmi_audio_update() {
    ...
    if (enabled && !(hdmi->power_on && hdmi->pixclock)) {
        DBG("disabling audio: no video");
        enabled = false;
    }

    /* Read first before writing */
    acr_pkt_ctrl = hdmi_read(hdmi, REG_HDMI_ACR_PKT_CTRL);
    ...
}

Even if msm_hdmi_audio_update() observes hdmi->power_on as false and sets
enabled = false, it proceeds unconditionally to execute the hdmi_read().

If msm_hdmi_bridge_atomic_post_disable() runs concurrently and calls
power_off(bridge) exactly between msm_hdmi_audio_update() checking
hdmi->power_on and attempting the MMIO read, can this result in an unclocked
MMIO access exception that crashes the system?

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

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