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