Re: [PATCH v3 1/3] drm/rockchip: dsi: Add maximum per lane bit rate calculation

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Potential divide-by-zero kernel panic if the PLL reference clock returns a rate of 0 Hz.
--

--- Patch [1]: [PATCH v3 1/3] drm/rockchip: dsi: Add maximum per lane bit rate calculation ---
commit d9f1ff11296ed644cdf72ac949c279cf1d55f770
Author: Chaoyi Chen <chaoyi.chen@rock-chips.com>

drm/rockchip: dsi: Add maximum per lane bit rate calculation

This commit adds calculations for the maximum per-lane bit rate across
various rockchip platforms. It introduces a new max_bit_rate_per_lane field
to the chip data and uses it to determine the max_mbps dynamically.

> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index 268d4993a04fd..fd91343d0f6d5 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
[ ... ]
> @@ -572,6 +573,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
>  	unsigned long _fbdiv, best_fbdiv;
>  	unsigned long min_delta = ULONG_MAX;
>  
> +	max_mbps = dsi->cdata->max_bit_rate_per_lane / USEC_PER_SEC;
>  	dsi->format = format;
>  	bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
>  	if (bpp < 0) {

[Severity: High]
This is a pre-existing issue, but while reviewing this function, I noticed
a potential divide-by-zero vulnerability further down in
dw_mipi_dsi_get_lane_mbps().

If clk_get_rate(dsi->pllref_clk) returns 0, which could occur if the clock
provider is uninitialized, disabled, or misconfigured in the device tree,
fin becomes 0. The calculations for min_prediv and max_prediv would then
both evaluate to 0.

This would cause the subsequent loop to execute once with _prediv = 0:

	for (_prediv = min_prediv; _prediv <= max_prediv; _prediv++) {
		u64 tmp;
		u32 delta;
		/* Fvco = Fref * M / N */
		tmp = (u64)fout * _prediv;
		do_div(tmp, fin);

Could this do_div(tmp, fin) trigger a kernel panic due to division by zero?

Would it make sense to add a check validating that fin is greater than zero
before proceeding with the calculation?

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