[PATCH 3/4] drm/msm/dp: skip LTTPR init when no LTTPRs are present

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Skipping `drm_dp_lttpr_init()` for negative `lttpr_count` bypasses the required LTTPR transparent mode fallback and is based on a flawed premise.
--

--- Patch [3]: [PATCH 3/4] drm/msm/dp: skip LTTPR init when no LTTPRs are present ---
commit 586e314c50820df2341a91e8a30d3963d3346281
Author: Saurabh Anand <saurabh.anand at oss.qualcomm.com>

drm/msm/dp: skip LTTPR init when no LTTPRs are present

This patch adds an early return when drm_dp_lttpr_count() returns a zero or
negative value. The goal is to skip LTTPR initialization when no repeaters
are detected or an error occurs reading the count.

> drm_dp_lttpr_count() returns 0 when no LTTPRs are detected and a
> negative value on error. The previous code passed the result directly
> to drm_dp_lttpr_init() without checking, which would call into the
> LTTPR transparency-mode setup with a zero or negative repeater count.

Is this description of drm_dp_lttpr_init() accurate?

Looking at drm_dp_lttpr_init(), it safely returns 0 on its own if
lttpr_count is zero:

int drm_dp_lttpr_init(struct drm_dp_aux *aux, int lttpr_count)
{
	int ret;

	if (!lttpr_count)
		return 0;
	...
}

It appears it already avoids calling into the transparency-mode setup
when the count is zero.

> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -253,6 +253,10 @@ static int msm_dp_display_lttpr_init(struct msm_dp_display_private *dp, u8 *dpcd
>  		return 0;
>  
>  	lttpr_count = drm_dp_lttpr_count(dp->link->lttpr_common_caps);
> +
> +	if (lttpr_count <= 0)
> +		return 0;
> +

[Severity: Medium]
Does skipping drm_dp_lttpr_init() for negative counts bypass the required
transparent mode fallback for non-compliant repeaters?

Looking at drm_dp_lttpr_init() in drivers/gpu/drm/display/drm_dp_helper.c,
it relies on receiving negative counts to trigger its fallback logic:

int drm_dp_lttpr_init(struct drm_dp_aux *aux, int lttpr_count)
{
	...
	ret = drm_dp_lttpr_set_transparent_mode(aux, true);
	if (ret)
		return ret;

	if (lttpr_count < 0)
		return -ENODEV;
	...
}

When lttpr_count is negative (e.g., -ERANGE or -EINVAL), the early return in
msm_dp_display_lttpr_init() causes the fallback to force transparent mode to
be entirely skipped. Could this cause link training to fail on setups with
non-compliant LTTPRs where the repeater count is invalid?

>  	rc = drm_dp_lttpr_init(dp->aux, lttpr_count);
>  	if (rc) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260824-qcom-dp-typec-reconnect-fixes-v1-0-2825e5bf8a96@oss.qualcomm.com?part=3