All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>
Cc: dri-devel@lists.freedesktop.org, olteanv@gmail.com,
	vkoul@kernel.org, linux-phy@lists.infradead.org,
	neil.armstrong@linaro.org
Subject: Re: [PATCH 1/2] phy: mediatek: phy-mtk-hdmi-mt8195: Fix PLL calc divisor overflow
Date: Wed, 01 Jul 2026 12:31:05 +0000	[thread overview]
Message-ID: <20260701123106.1B5801F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260701121936.19407-2-angelogioacchino.delregno@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Calculations using `14835 * MEGA`, `5 * GIGA`, and `12 * GIGA` silently overflow 32-bit `unsigned long` types on 32-bit architectures, completely breaking clock tiering and boundary checks.
--

commit 8179a32cf1dac8f1d080e57bbce79246661b50eb
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

phy: mediatek: phy-mtk-hdmi-mt8195: Fix PLL calc divisor overflow

This commit fixes an issue where calculating a PLL rate for high display
resolutions results in a pixel clock exceeding 32 bits, but the digital
clock divider calculation uses div_u64(), which expects a 32-bit divisor.
It resolves this by using div64_u64() instead to prevent overflow.

> diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> index 1426a2db984d5..e6ee8e0800222 100644
> --- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> @@ -290,7 +290,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy, struct clk_hw *hw,

[Severity: High]
This is a pre-existing issue, but do the constants in this function silently
overflow on 32-bit architectures?

Earlier in mtk_hdmi_pll_calc(), there are tier threshold calculations like:

    else if ((tmds_clk * 100) >= 14835 * MEGA && (tmds_clk * 10) < 2967 * MEGA)

and later boundary checks:

    if (ns_hdmipll_ck >= 5 * GIGA &&
        ns_hdmipll_ck <= 12 * GIGA)

If MEGA and GIGA evaluate as 32-bit types on 32-bit systems, a multiplication
like 14835 * MEGA evaluates to 14,835,000,000, which wraps around modulo 2^32
to 1,950,098,112 before being promoted to u64 for the comparison against
tmds_clk * 100.

Similarly, 5 * GIGA and 12 * GIGA would overflow, potentially rendering the
valid PLL clock range mathematically unreachable and forcing the function to
always return -EINVAL on 32-bit builds.

Should these constants be explicitly typed or cast to u64 to ensure the
comparisons work correctly on 32-bit kernels?

>  	posdiv2 = 1;
>  
>  	/* Digital clk divider, max /32 */
> -	digital_div = div_u64(ns_hdmipll_ck, posdiv1 * posdiv2 * pixel_clk);
> +	digital_div = div64_u64(ns_hdmipll_ck, posdiv1 * posdiv2 * pixel_clk);
>  	if (!(digital_div <= 32 && digital_div >= 1))
>  		return -EINVAL;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701121936.19407-1-angelogioacchino.delregno@collabora.com?part=1

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>
Cc: dri-devel@lists.freedesktop.org, olteanv@gmail.com,
	vkoul@kernel.org, linux-phy@lists.infradead.org,
	neil.armstrong@linaro.org
Subject: Re: [PATCH 1/2] phy: mediatek: phy-mtk-hdmi-mt8195: Fix PLL calc divisor overflow
Date: Wed, 01 Jul 2026 12:31:05 +0000	[thread overview]
Message-ID: <20260701123106.1B5801F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260701121936.19407-2-angelogioacchino.delregno@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Calculations using `14835 * MEGA`, `5 * GIGA`, and `12 * GIGA` silently overflow 32-bit `unsigned long` types on 32-bit architectures, completely breaking clock tiering and boundary checks.
--

commit 8179a32cf1dac8f1d080e57bbce79246661b50eb
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

phy: mediatek: phy-mtk-hdmi-mt8195: Fix PLL calc divisor overflow

This commit fixes an issue where calculating a PLL rate for high display
resolutions results in a pixel clock exceeding 32 bits, but the digital
clock divider calculation uses div_u64(), which expects a 32-bit divisor.
It resolves this by using div64_u64() instead to prevent overflow.

> diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> index 1426a2db984d5..e6ee8e0800222 100644
> --- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> @@ -290,7 +290,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy, struct clk_hw *hw,

[Severity: High]
This is a pre-existing issue, but do the constants in this function silently
overflow on 32-bit architectures?

Earlier in mtk_hdmi_pll_calc(), there are tier threshold calculations like:

    else if ((tmds_clk * 100) >= 14835 * MEGA && (tmds_clk * 10) < 2967 * MEGA)

and later boundary checks:

    if (ns_hdmipll_ck >= 5 * GIGA &&
        ns_hdmipll_ck <= 12 * GIGA)

If MEGA and GIGA evaluate as 32-bit types on 32-bit systems, a multiplication
like 14835 * MEGA evaluates to 14,835,000,000, which wraps around modulo 2^32
to 1,950,098,112 before being promoted to u64 for the comparison against
tmds_clk * 100.

Similarly, 5 * GIGA and 12 * GIGA would overflow, potentially rendering the
valid PLL clock range mathematically unreachable and forcing the function to
always return -EINVAL on 32-bit builds.

Should these constants be explicitly typed or cast to u64 to ensure the
comparisons work correctly on 32-bit kernels?

>  	posdiv2 = 1;
>  
>  	/* Digital clk divider, max /32 */
> -	digital_div = div_u64(ns_hdmipll_ck, posdiv1 * posdiv2 * pixel_clk);
> +	digital_div = div64_u64(ns_hdmipll_ck, posdiv1 * posdiv2 * pixel_clk);
>  	if (!(digital_div <= 32 && digital_div >= 1))
>  		return -EINVAL;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701121936.19407-1-angelogioacchino.delregno@collabora.com?part=1

  reply	other threads:[~2026-07-01 12:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01 12:19 [PATCH 0/2] MediaTek MT8195 HDMI PHY Fixes AngeloGioacchino Del Regno
2026-07-01 12:19 ` AngeloGioacchino Del Regno
2026-07-01 12:19 ` [PATCH 1/2] phy: mediatek: phy-mtk-hdmi-mt8195: Fix PLL calc divisor overflow AngeloGioacchino Del Regno
2026-07-01 12:19   ` AngeloGioacchino Del Regno
2026-07-01 12:31   ` sashiko-bot [this message]
2026-07-01 12:31     ` sashiko-bot
2026-07-07 14:14     ` AngeloGioacchino Del Regno
2026-07-07 14:14       ` AngeloGioacchino Del Regno
2026-07-01 12:19 ` [PATCH 2/2] phy: mediatek: phy-mtk-hdmi-mt8195: Fix TMDS clk bit ratio setting AngeloGioacchino Del Regno
2026-07-01 12:19   ` AngeloGioacchino Del Regno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260701123106.1B5801F00A3E@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.