Re: [PATCH v4 09/12] 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] For eDP, mode validation and bus format negotiation incorrectly use the SoC's hardware maximum link rate rather than considering the board's device tree limit and the sink's DPCD capabilities.
--

--- Patch [9]: [PATCH v4 09/12] drm/mediatek: mtk_dp: Move max link rate to SoC specific data ---
commit 77698e671819e17e65d99b3fb9908f2be60bc613
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
drm/mediatek: mtk_dp: Move max link rate to SoC specific data

This commit moves the hardware maximum link rate from static initialization
to SoC-specific data to prepare for supporting MT8196 eDP IP which has a
higher maximum link rate.

> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> index e2a6001fc0ccc..ea970a9bfe936 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
[ ... ]
> @@ -1469,7 +1470,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 this blind initialization
cause mode validation to falsely accept unsupported high-bandwidth modes?

Because mtk_dp_bridge_mode_valid() and 
mtk_dp_bridge_atomic_get_input_bus_fmts() are called before atomic_enable() 
during mode enumeration, they evaluate available bandwidth using this 
un-negotiated train_info.link_rate:

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

For eDP connections, actual link training is deferred until 
mtk_dp_bridge_atomic_enable(). Using the un-negotiated rate here ignores the 
board's device tree limit (max-linkrate-mhz) and the sink's DPCD capabilities.

Can this result in configuring a display mode that exceeds the actual link
bandwidth, leading to link training failures or black screens, and failing
to fall back to bandwidth-saving formats like YUV422?

>  	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/20260709113148.49090-1-angelogioacchino.delregno@collabora.com?part=9