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 <[email protected]> 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-dcf895687...@oss.qualcomm.com?part=3
