Re: [PATCH v7 07/13] drm/mediatek: mtk_dsi: Move max link rate parameter to platform data

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] mtk_dsi_bridge_atomic_pre_enable ignores mtk_dsi_poweron failure and accesses registers without clocks.
--

commit 5b6418994a183b2b2cc5727632b7cacb276f50a5
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

drm/mediatek: mtk_dsi: Move max link rate parameter to platform data

This commit moves the max link rate configuration to SoC-specific platform
data to support newer MediaTek IPs capable of up to 2.5Gbps. It also updates
the data rate calculation to prevent integer overflows at higher clocks.

> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index fa0f404bc7add..6e92e4e1586f7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
[ ... ]
> @@ -921,7 +923,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>  	}
>  	bit_per_pixel = ret;
>  
> -	dsi->data_rate = DIV_ROUND_UP_ULL(dsi->vm.pixelclock * bit_per_pixel,
> +	dsi->data_rate = DIV_ROUND_UP_ULL((u64)dsi->vm.pixelclock * bit_per_pixel,
>  					  dsi->lanes);
>  
>  	ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);

[Severity: High]
This is a pre-existing issue, but does mtk_dsi_bridge_atomic_pre_enable()
safely handle failures from mtk_dsi_poweron()?

If mtk_dsi_poweron() fails (for example, if clk_set_rate() fails here, or if
phy_power_on() fails later), it rolls back the clock state and returns a
negative error.

However, the caller in drivers/gpu/drm/mediatek/mtk_dsi.c:

mtk_dsi_bridge_atomic_pre_enable() {
    ...
    ret = mtk_dsi_poweron(dsi);
    if (ret < 0)
        drm_err(drm, "failed to power on dsi\n");

    mtk_dsi_lane_ready(dsi);
    ...
}

logs the error but continues execution instead of returning early. It then
immediately calls mtk_dsi_lane_ready(), which attempts to access DSI hardware
registers (such as DSI_TXRX_CTRL) while the DSI clocks are disabled.

Could this trigger an AXI bus timeout and cause a hard system hang when the
unclocked register access occurs?

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