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 <[email protected]>

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/[email protected]?part=1

Reply via email to