Re: [PATCH 08/11] drm/mediatek: mtk_dp: Move max link rate to SoC specific data

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] mode_valid and atomic_get_input_bus_fmts validate display modes against an unbounded, stale, or uninitialized link rate, bypassing Device Tree limits and DPCD capabilities.
--

commit 4683d3daece6ab3ba3c7c82ebff7364e878794fb
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Wed Jul 1 12:20:21 2026 +0000

drm/mediatek: mtk_dp: Move max link rate to SoC specific data

This patch moves the maximum link rate to the SoC specific data structure
instead of statically assigning it to DP_LINK_BW_5_4 during initialization.
This prepares the driver for the MT8196 SoC which supports higher link rates.

> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> index bf3a4b15f3ec0..5272e717bfda0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
[ ... ]
> @@ -1481,7 +1482,7 @@ static void mtk_dp_initialize_priv_data(struct mtk_dp *mtk_dp)
>  {
>  	bool plugged_in = (mtk_dp->bridge.type == DRM_MODE_CONNECTOR_eDP);
>  
> -	mtk_dp->train_info.link_rate = DP_LINK_BW_5_4;
> +	mtk_dp->train_info.link_rate = mtk_dp->data->hw_max_link_rate;

[Severity: High]
This isn't a bug introduced by this patch, but does setting the link rate
here cause mode validation to falsely accept unsupported high-bandwidth modes?

Looking at mtk_dp_bridge_mode_valid() in drivers/gpu/drm/mediatek/mtk_dp.c,
it calculates available bandwidth using the unnegotiated train_info.link_rate:

	u32 rate = drm_dp_bw_code_to_link_rate(mtk_dp->train_info.link_rate) *
		   lane_count_min;

A similar calculation occurs in mtk_dp_bridge_atomic_get_input_bus_fmts().

Since train_info.link_rate is initialized here to the SoC's absolute maximum
(and previously statically to DP_LINK_BW_5_4), it bypasses the board-specific
Device Tree constraint mtk_dp->max_linkrate and the sink capabilities in rx_cap.

When the mode is actually committed, mtk_dp_training() properly limits the
link rate to mtk_dp->max_linkrate and trains at a lower bandwidth. Won't this
leave the hardware unable to sustain the falsely validated high-bandwidth
display mode, resulting in a blank screen or corrupted output due to bandwidth
exhaustion?

Because this patch will introduce even higher initial values for future SoCs
like MT8196, will this cause a wider range of unsupported modes to be falsely
validated?

>  	mtk_dp->train_info.lane_count = mtk_dp->max_lanes;
>  	mtk_dp->train_info.cable_plugged_in = plugged_in;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701122024.19557-1-angelogioacchino.delregno@collabora.com?part=8