Re: [PATCH v4 16/20] phy: Add common Innosilicon HDMI PHY helpers
From: sashiko-bot@kernel.org
Date: 2026-09-15 15:42:55
Also in:
dri-devel, linux-clk, linux-devicetree
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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 -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy