[PATCH v4 2/8] phy: rockchip: samsung-hdptx: Prevent divide-by-zero when computing clk rate

[sashiko-bot at kernel.org]

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

Pre-existing issues:
- [High] Potential integer underflow in `fout` calculation when hardware state is misconfigured, leading to a massive bogus clock rate that could hang downstream components.
--

commit cb21c8c13b880d08d17b5ee69740229527db5442
Author: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>

phy: rockchip: samsung-hdptx: Prevent divide-by-zero when computing clk rate

This commit adds sanitization to rk_hdptx_phy_clk_calc_rate_from_pll_cfg()
to prevent a divide-by-zero during clock rate calculation. It checks the
denominator derived from hardware registers, which could be uninitialized or
misconfigured.

Closes: https://sashiko.dev/#/patchset/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com?part=1

> diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> index 710603afff866..8c044381b83a4 100644
> --- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> +++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> @@ -2270,10 +2270,15 @@ static u64 rk_hdptx_phy_clk_calc_rate_from_pll_cfg(struct rk_hdptx_phy *hdptx)
>  
>  	fout = PLL_REF_CLK * ropll_hw.pms_mdiv;
>  	if (ropll_hw.sdm_en) {
> +		val = 16U * ropll_hw.sdm_deno *
> +		      (ropll_hw.sdc_deno * ropll_hw.sdc_n - ropll_hw.sdc_num);
> +		if (!val) {
> +			dev_dbg(hdptx->dev, "%s invalid ROPLL hw state\n", __func__);
> +			return 0;
> +		}
> +
>  		sdm = div_u64(PLL_REF_CLK * ropll_hw.sdc_deno *
> -			      ropll_hw.pms_mdiv * ropll_hw.sdm_num,
> -			      16 * ropll_hw.sdm_deno *
> -			      (ropll_hw.sdc_deno * ropll_hw.sdc_n - ropll_hw.sdc_num));
> +			      ropll_hw.pms_mdiv * ropll_hw.sdm_num, val);
>  
>  		if (ropll_hw.sdm_num_sign)
>  			fout = fout - sdm;

[Severity: High]
This is a pre-existing issue, but could this subtraction result in an
integer underflow?

If the hardware registers are misconfigured or contain uninitialized values,
it seems the computed sigma-delta modulator offset sdm could be significantly
larger than the base frequency fout.

Since fout is an unsigned 64-bit integer, subtracting a larger sdm in
rk_hdptx_phy_clk_calc_rate_from_pll_cfg() would wrap around to a massive
positive value.

Could this underflow lead to an absurdly high clock rate being returned
to the Common Clock Framework, potentially causing hangs or div-by-zero
errors in downstream components?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-hdptx-clk-fixes-v4-0-ce5e1d456cda@collabora.com?part=2