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
[ ... ]
quoted hunk ↗ jump to hunk
+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.
quoted hunk ↗ jump to hunk
+
+ 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.
quoted hunk ↗ jump to hunk
+ }
+
+ 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.
quoted hunk ↗ jump to hunk
+ } 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.
quoted hunk ↗ jump to hunk
+ }
+
+ 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