Re: [PATCH v6 09/29] drm/msm/dp: add support to enable MST in mainlink control

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Sleeping function msleep() is called in an atomic commit context via msm_dp_ctrl_mst_send_act().
--

commit 10a0de5e53b18299bcdd23065b77d3e1f1d02df3
Author: Abhinav Kumar <quic_abhinavk@quicinc.com>

drm/msm/dp: add support to enable MST in mainlink control

This commit adds support to program the MST enable bit in the mainlink control 
register when an MST session is active or being disabled.

> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 65d22505c2b67..cd6ae0d5372c9 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -276,6 +276,19 @@ int msm_dp_ctrl_mst_send_act(struct msm_dp_ctrl *msm_dp_ctrl,

[Severity: High]
This isn't a bug introduced by this patch, but it is a pre-existing High
severity issue that persists through the end of the series.

Does this code call a sleeping function from an atomic context?

Looking at msm_dp_ctrl_mst_send_act(), it executes a sleeping delay:

int msm_dp_ctrl_mst_send_act(...)
{
    ...
    msleep(frame_time_ms);
    ...
}

Calling a sleeping function like msleep() from an atomic context causes kernel
warnings (might_sleep()), system instability, and potential deadlocks on hot
paths.

This appears to be triggered on an atomic commit path:
msm_dp_display_atomic_enable() (an encoder/bridge atomic enable callback)
calls msm_dp_display_enable(), which calls msm_dp_ctrl_on_stream(), which in
turn calls msm_dp_ctrl_mst_send_act().

A similar path exists during disable:
msm_dp_display_atomic_disable() -> msm_dp_ctrl_mst_send_act().

The DRM Subsystem Details explicitly define encoder atomic enable/disable
callbacks as atomic context paths where sleeping is strictly forbidden. Only
non-sleeping delays (udelay, ndelay) are safe.

Checking the final state of the series (commit 48ec7f7903ee) confirms this bug
is not resolved later; dpu_encoder_mst_atomic_disable() still calls
msm_dp_mst_stream_disable(), which reaches msm_dp_ctrl_mst_send_act() and
sleeps.

>  	return 0;
>  }
>  
> +static void msm_dp_ctrl_mst_config(struct msm_dp_ctrl_private *ctrl, bool enable)
> +{
> +	u32 mainlink_ctrl;
> +
> +	mainlink_ctrl = msm_dp_read_link(ctrl, REG_DP_MAINLINK_CTRL);
> +	if (enable)
> +		mainlink_ctrl |= DP_MAINLINK_CTRL_MST_EN;
> +	else
> +		mainlink_ctrl &= ~DP_MAINLINK_CTRL_MST_EN;
> +
> +	msm_dp_write_link(ctrl, REG_DP_MAINLINK_CTRL, mainlink_ctrl);
> +}

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831-msm-dp-mst-v6-0-c91d35d6fb9e@oss.qualcomm.com?part=9