[PATCH v4 16/20] phy: Add common Innosilicon HDMI PHY helpers

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] phy: division by zero kernel panic in recalc_rate() on register read failure
--

commit 543e5d00d9e079829f4ad47de05248c127f81d1c
Author: Michal Wilczynski <m.wilczynski at samsung.com>

phy: Add common Innosilicon HDMI PHY helpers

This commit adds a common library for the Innosilicon HDMI PHY IP, which
is used by several SoCs. It extracts the pre-PLL configuration table
format, lookups, and clock rate helpers into shared code.

> diff --git a/drivers/phy/phy-inno-hdmi.c b/drivers/phy/phy-inno-hdmi.c
> new file mode 100644
> index 0000000000000..77e745a87d22b
> --- /dev/null
> +++ b/drivers/phy/phy-inno-hdmi.c

[ ... ]

> +unsigned long
> +inno_hdmi_phy_pre_pll_recalc_rate(const struct inno_hdmi_phy_pre_pll *pll,
> +				  unsigned long parent_rate)
> +{
> +	u8 nd, no_a, no_b, no_d;
> +	unsigned long frac, rate;
> +	u64 vco, vco_rate;
> +	u16 nf;
> +
> +	nd = inno_read(pll, INNO_PRE_PLL_DIV_1) & INNO_PRE_PLL_PRE_DIV_MASK;
> +	nf = (inno_read(pll, INNO_PRE_PLL_DIV_2) &
> +	      INNO_PRE_PLL_FB_DIV_11_8_MASK) << 8;
> +	nf |= inno_read(pll, INNO_PRE_PLL_DIV_3);
> +	vco = parent_rate * nf;

[Severity: High]
This is a pre-existing issue, but does this code cause an integer overflow
on 32-bit architectures?

When inno_hdmi_phy_pre_pll_recalc_rate() executes, parent_rate * nf
multiplies two 32-bit integers, which could silently overflow before
assignment to the 64-bit vco variable.

> +
> +	if (!(inno_read(pll, INNO_PRE_PLL_DIV_2) &
> +	      INNO_PRE_PLL_FRAC_DIV_DISABLE)) {
> +		frac = inno_read(pll, INNO_PRE_PLL_FRAC_DIV_7_0) |
> +		       (inno_read(pll, INNO_PRE_PLL_FRAC_DIV_15_8) << 8) |
> +		       (inno_read(pll, INNO_PRE_PLL_FRAC_DIV_23_16) << 16);
> +		vco += DIV_ROUND_CLOSEST(parent_rate * frac,
> +					 BIT(INNO_FRAC_DIV_WIDTH));

[Severity: High]
This isn't a bug introduced by this patch, but does parent_rate * frac
also massively overflow before rounding on 32-bit systems?

Since parent_rate is typically 24MHz and frac is a 24-bit divider, their
product exceeds the 32-bit maximum. This causes silent truncation and leads
to completely incorrect calculated VCO rates.

> +	}
> +
> +	vco_rate = vco;
> +
> +	if (inno_read(pll, INNO_PRE_PLL_CONTROL) & INNO_PCLK_VCO_DIV_5_MASK) {
> +		do_div(vco, nd * 5);

[Severity: High]
Can this result in a division by zero kernel panic?

inno_read() returns 0 if regmap_read() fails. If nd evaluates to 0 due to
an uninitialized register or a read failure, the denominator becomes 0.

> +	} else {
> +		no_a = inno_read(pll, INNO_PCLK_DIV_AB) & INNO_PCLK_DIV_A_MASK;
> +		no_b = FIELD_GET(INNO_PCLK_DIV_B_MASK,
> +				 inno_read(pll, INNO_PCLK_DIV_AB)) + 2;
> +		no_d = inno_read(pll, INNO_PCLK_DIV_CD) & INNO_PCLK_DIV_D_MASK;
> +
> +		do_div(vco, nd * (no_a == 1 ? no_b : no_a) * no_d * 2);

[Severity: High]
Could this also trigger a division by zero crash?

If nd, no_a, or no_d evaluates to 0 due to read failures, the denominator
becomes 0.

The legacy RK3228 driver guarded against no_a being 0 with an explicit
check (if (!no_a) no_a = 1;), but it appears this protection was removed
when creating this shared code.

> +	}
> +
> +	rate = DIV_ROUND_CLOSEST((unsigned long)vco, 1000) * 1000;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915-jh7110-clean-send-v4-0-f0e4fd6f2cc8@samsung.com?part=16