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