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

[Cristian Ciocaltea]

On 6/12/26 2:57 AM, sashiko-bot at kernel.org wrote:
> 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.
> --

If the hardware reached such a damaged state, the kernel is likely already encountering more serious issues.

Regardless, I will address this in the "FRL TxFFE level control" series, which is currently blocked by this one, to avoid any further delays.

Regards,
Cristian

> 
> 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?
>