Re: [PATCH v5 3/3] drm/rockchip: dsi: Relax the lane rate margin requirements

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] 32-bit integer overflow in PHY pixel clock calculation limits maximum pixel clock to 429.49 MHz.
--

commit 979a891d8dcf3f71d29e5487fb6d05be64459b38
Author: Chaoyi Chen <chaoyi.chen@rock-chips.com>

drm/rockchip: dsi: Relax the lane rate margin requirements

This commit relaxes the lane rate margin requirements for the rockchip
dw-mipi-dsi driver to accommodate platforms with a 1Gbps lane rate limit.
It updates the bandwidth calculations to use an 11% overhead instead of 25%.

> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index aab3353945de5..76607eac470a3 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c

[ ... ]

> @@ -600,7 +600,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
>  
>  	/* for external phy only a the mipi_dphy_config is necessary */
>  	if (dsi->phy) {
> -		phy_mipi_dphy_get_default_config(mode->clock * 1000 * 10 / 8,
> +		phy_mipi_dphy_get_default_config((u32)mode->clock * 1000 * 10 / 9,

[Severity: High]
This isn't a bug introduced by this patch, but does this calculation still
overflow for pixel clocks greater than 429.49 MHz?

The original code overflowed at 214 MHz due to signed 32-bit math. While the
addition of the (u32) cast prevents the signed overflow, the arithmetic
(u32)mode->clock * 1000 * 10 still evaluates within 32-bit bounds before
being promoted to the 64-bit unsigned long parameter of
phy_mipi_dphy_get_default_config() in dw_mipi_dsi_get_lane_mbps().

For a MIPI DSI panel with a high pixel clock, such as 450 MHz, the
calculation evaluates to 4,500,000,000. This exceeds U32_MAX and wraps
around, configuring the PHY with a drastically lower clock frequency and
resulting in link training failures.

Could this be resolved by casting to u64 or using mul_u32_u32() to ensure
the intermediate multiplication doesn't overflow?

>  						 bpp, lanes,
>  						 &dsi->phy_opts.mipi_dphy);
>  		dsi->lane_mbps = target_mbps;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914013331.108-1-kernel@airkyi.com?part=3