From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: sashiko-reviews@lists.linux.dev
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: Tue, 7 Jul 2026 16:14:41 +0200 [thread overview]
Message-ID: <568124de-9ed6-469a-8521-99c11cd6c495@collabora.com> (raw)
In-Reply-To: <20260701123106.1B5801F00A3E@smtp.kernel.org>
On 7/1/26 14:31, sashiko-bot@kernel.org wrote:
> 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?
>
There is no 32-bit architecture compatible with this driver. This will run only
on AArch64, and it's very unlikely to see a 32-bits kernel running on MT8195.
This can be eventually fixed with a later series, but shall not block the proposed
fixes from being picked, both because it's unlikely to happen, and because those
are pre-existing issues.
Besides, the series *is* actually fixing some other overflow issues and was already
tested good.
> 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;
>>
>
WARNING: multiple messages have this Message-ID (diff)
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: sashiko-reviews@lists.linux.dev
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: Tue, 7 Jul 2026 16:14:41 +0200 [thread overview]
Message-ID: <568124de-9ed6-469a-8521-99c11cd6c495@collabora.com> (raw)
In-Reply-To: <20260701123106.1B5801F00A3E@smtp.kernel.org>
On 7/1/26 14:31, sashiko-bot@kernel.org wrote:
> 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?
>
There is no 32-bit architecture compatible with this driver. This will run only
on AArch64, and it's very unlikely to see a 32-bits kernel running on MT8195.
This can be eventually fixed with a later series, but shall not block the proposed
fixes from being picked, both because it's unlikely to happen, and because those
are pre-existing issues.
Besides, the series *is* actually fixing some other overflow issues and was already
tested good.
> 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;
>>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-07-07 14:14 UTC|newest]
Thread overview: 16+ 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
2026-07-01 12:31 ` sashiko-bot
2026-07-07 14:14 ` AngeloGioacchino Del Regno [this message]
2026-07-07 14:14 ` AngeloGioacchino Del Regno
2026-09-09 15:04 ` Manivannan Sadhasivam
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
2026-09-09 15:06 ` Manivannan Sadhasivam
2026-09-10 8:39 ` AngeloGioacchino Del Regno
2026-09-11 5:11 ` Manivannan Sadhasivam
2026-09-11 7:36 ` AngeloGioacchino Del Regno
2026-09-09 12:07 ` [PATCH 0/2] MediaTek MT8195 HDMI PHY Fixes 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=568124de-9ed6-469a-8521-99c11cd6c495@collabora.com \
--to=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.