From: sashiko-bot@kernel.org
To: "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, vkoul@kernel.org,
conor+dt@kernel.org, linux-phy@lists.infradead.org,
olteanv@gmail.com, neil.armstrong@linaro.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 10/12] phy: phy-mtk-dp: Add bitrate register val definitions to SoC data
Date: Wed, 01 Jul 2026 13:02:23 +0000 [thread overview]
Message-ID: <20260701130223.CF9691F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701122008.19509-11-angelogioacchino.delregno@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mtk_dp_phy_disable_all_lanes loop executes undefined behavior when val is 0, and incorrectly clears lane bits using the lane index instead of a bitmask.
--
commit 25cdd51bd1ac4d69a49e77d93a6b1374ba46dd3c
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
phy: phy-mtk-dp: Support set_lanes in configure and properly cleanup
Add support for enabling a specifically requested number of lanes in the
configure callback, and disable all lanes in power off and reset
callbacks for proper hardware cleanup.
> diff --git a/drivers/phy/mediatek/phy-mtk-dp.c b/drivers/phy/mediatek/phy-mtk-dp.c
> index 586e727956332..a2cd22b9da066 100644
> --- a/drivers/phy/mediatek/phy-mtk-dp.c
> +++ b/drivers/phy/mediatek/phy-mtk-dp.c
[ ... ]
> @@ -261,6 +267,35 @@ static int mtk_dp_phy_power_on(struct phy *phy)
> return 0;
> }
>
> +static int mtk_dp_phy_disable_all_lanes(struct mtk_dp_phy *dp_phy)
> +{
> + const struct mtk_dp_phy_pdata *pdata = dp_phy->pdata;
> + const u8 *regs = pdata->regs_dig_glb;
> + int ret;
> + u32 val;
> +
> + ret = regmap_read(dp_phy->regmap, pdata->off_dig_glb + regs[DP_PHYD_TX_CTL_0], &val);
> + if (ret)
> + return ret;
> +
> + /* Get mask of currently enabled lane */
> + val = FIELD_GET(PHYD_TX_LN_EN, val);
> +
> + /* Disable all lanes (needs to be done one by one, from last to first) */
> + do {
> + u32 lane_num = fls(val) - 1;
[Severity: High]
If no lanes are currently enabled, val will be 0. Does this cause fls(0) - 1
to underflow, leading to undefined behavior when computing BIT(lane_num)?
> + val &= ~BIT(lane_num);
> +
> + ret = regmap_clear_bits(dp_phy->regmap,
> + pdata->off_dig_glb + regs[DP_PHYD_TX_CTL_0],
> + FIELD_PREP(PHYD_TX_LN_EN, lane_num));
[Severity: High]
Does this incorrectly clear bits using the lane index instead of a bitmask?
For example, if lane 3 is being disabled (lane_num == 3), this passes 3 to
FIELD_PREP instead of BIT(3). This would clear lanes 0 and 1 (3 << 4) while
leaving lane 3 enabled. Should this use BIT(lane_num) instead?
> + if (ret)
> + return ret;
> + } while (val);
> +
> + return 0;
> +}
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701122008.19509-1-angelogioacchino.delregno@collabora.com?part=10
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, vkoul@kernel.org,
conor+dt@kernel.org, linux-phy@lists.infradead.org,
olteanv@gmail.com, neil.armstrong@linaro.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 10/12] phy: phy-mtk-dp: Add bitrate register val definitions to SoC data
Date: Wed, 01 Jul 2026 13:02:23 +0000 [thread overview]
Message-ID: <20260701130223.CF9691F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701122008.19509-11-angelogioacchino.delregno@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mtk_dp_phy_disable_all_lanes loop executes undefined behavior when val is 0, and incorrectly clears lane bits using the lane index instead of a bitmask.
--
commit 25cdd51bd1ac4d69a49e77d93a6b1374ba46dd3c
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
phy: phy-mtk-dp: Support set_lanes in configure and properly cleanup
Add support for enabling a specifically requested number of lanes in the
configure callback, and disable all lanes in power off and reset
callbacks for proper hardware cleanup.
> diff --git a/drivers/phy/mediatek/phy-mtk-dp.c b/drivers/phy/mediatek/phy-mtk-dp.c
> index 586e727956332..a2cd22b9da066 100644
> --- a/drivers/phy/mediatek/phy-mtk-dp.c
> +++ b/drivers/phy/mediatek/phy-mtk-dp.c
[ ... ]
> @@ -261,6 +267,35 @@ static int mtk_dp_phy_power_on(struct phy *phy)
> return 0;
> }
>
> +static int mtk_dp_phy_disable_all_lanes(struct mtk_dp_phy *dp_phy)
> +{
> + const struct mtk_dp_phy_pdata *pdata = dp_phy->pdata;
> + const u8 *regs = pdata->regs_dig_glb;
> + int ret;
> + u32 val;
> +
> + ret = regmap_read(dp_phy->regmap, pdata->off_dig_glb + regs[DP_PHYD_TX_CTL_0], &val);
> + if (ret)
> + return ret;
> +
> + /* Get mask of currently enabled lane */
> + val = FIELD_GET(PHYD_TX_LN_EN, val);
> +
> + /* Disable all lanes (needs to be done one by one, from last to first) */
> + do {
> + u32 lane_num = fls(val) - 1;
[Severity: High]
If no lanes are currently enabled, val will be 0. Does this cause fls(0) - 1
to underflow, leading to undefined behavior when computing BIT(lane_num)?
> + val &= ~BIT(lane_num);
> +
> + ret = regmap_clear_bits(dp_phy->regmap,
> + pdata->off_dig_glb + regs[DP_PHYD_TX_CTL_0],
> + FIELD_PREP(PHYD_TX_LN_EN, lane_num));
[Severity: High]
Does this incorrectly clear bits using the lane index instead of a bitmask?
For example, if lane 3 is being disabled (lane_num == 3), this passes 3 to
FIELD_PREP instead of BIT(3). This would clear lanes 0 and 1 (3 << 4) while
leaving lane 3 enabled. Should this use BIT(lane_num) instead?
> + if (ret)
> + return ret;
> + } while (val);
> +
> + return 0;
> +}
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701122008.19509-1-angelogioacchino.delregno@collabora.com?part=10
--
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-01 13:02 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 12:19 [PATCH 00/12] PHY: MediaTek DP PHY refactor and MT8196 eDP AngeloGioacchino Del Regno
2026-07-01 12:19 ` AngeloGioacchino Del Regno
2026-07-01 12:19 ` [PATCH 01/12] dt-bindings: phy: Document MT8195 and MT8196 DisplayPort PHYs AngeloGioacchino Del Regno
2026-07-01 12:19 ` AngeloGioacchino Del Regno
2026-07-01 12:27 ` sashiko-bot
2026-07-01 12:27 ` sashiko-bot
2026-07-01 13:07 ` AngeloGioacchino Del Regno
2026-07-01 13:07 ` AngeloGioacchino Del Regno
2026-07-01 14:38 ` Rob Herring (Arm)
2026-07-01 14:38 ` Rob Herring (Arm)
2026-07-01 12:19 ` [PATCH 02/12] phy: phy-mtk-dp: Rename regs to regmap in struct mtk_dp_phy AngeloGioacchino Del Regno
2026-07-01 12:19 ` AngeloGioacchino Del Regno
2026-07-01 12:26 ` sashiko-bot
2026-07-01 12:26 ` sashiko-bot
2026-07-01 13:05 ` AngeloGioacchino Del Regno
2026-07-01 13:05 ` AngeloGioacchino Del Regno
2026-07-01 12:19 ` [PATCH 03/12] phy: phy-mtk-dp: Allow probing with devicetree match AngeloGioacchino Del Regno
2026-07-01 12:19 ` AngeloGioacchino Del Regno
2026-07-01 12:30 ` sashiko-bot
2026-07-01 12:30 ` sashiko-bot
2026-07-01 12:20 ` [PATCH 04/12] phy: phy-mtk-dp: Migrate register offsets to SoC specific pdata AngeloGioacchino Del Regno
2026-07-01 12:20 ` AngeloGioacchino Del Regno
2026-07-01 12:36 ` sashiko-bot
2026-07-01 12:36 ` sashiko-bot
2026-07-01 12:20 ` [PATCH 05/12] phy: phy-mtk-dp: Implement power_on and power_off PHY callbacks AngeloGioacchino Del Regno
2026-07-01 12:20 ` AngeloGioacchino Del Regno
2026-07-01 12:39 ` sashiko-bot
2026-07-01 12:39 ` sashiko-bot
2026-07-01 12:20 ` [PATCH 06/12] phy: phy-mtk-dp: Support set_lanes in configure and properly cleanup AngeloGioacchino Del Regno
2026-07-01 12:20 ` AngeloGioacchino Del Regno
2026-07-01 12:35 ` sashiko-bot
2026-07-01 12:35 ` sashiko-bot
2026-07-01 12:20 ` [PATCH 07/12] phy: phy-mtk-dp: Support setting volt swing and preemphasis values AngeloGioacchino Del Regno
2026-07-01 12:20 ` AngeloGioacchino Del Regno
2026-07-01 12:49 ` sashiko-bot
2026-07-01 12:49 ` sashiko-bot
2026-07-01 12:20 ` [PATCH 08/12] phy: phy-mtk-dp: Add support for digital and analog calibration AngeloGioacchino Del Regno
2026-07-01 12:20 ` AngeloGioacchino Del Regno
2026-07-01 12:48 ` sashiko-bot
2026-07-01 12:48 ` sashiko-bot
2026-07-01 12:20 ` [PATCH 09/12] phy: phy-mtk-dp: Rewrite and document default driving param macros AngeloGioacchino Del Regno
2026-07-01 12:20 ` AngeloGioacchino Del Regno
2026-07-01 12:50 ` sashiko-bot
2026-07-01 12:50 ` sashiko-bot
2026-07-01 12:20 ` [PATCH 10/12] phy: phy-mtk-dp: Add bitrate register val definitions to SoC data AngeloGioacchino Del Regno
2026-07-01 12:20 ` AngeloGioacchino Del Regno
2026-07-01 13:02 ` sashiko-bot [this message]
2026-07-01 13:02 ` sashiko-bot
2026-07-01 12:20 ` [PATCH 11/12] phy: phy-mtk-dp: Add PHYD Lane EN register mask " AngeloGioacchino Del Regno
2026-07-01 12:20 ` AngeloGioacchino Del Regno
2026-07-01 13:07 ` sashiko-bot
2026-07-01 13:07 ` sashiko-bot
2026-07-01 12:20 ` [PATCH 12/12] phy: phy-mtk-dp: Add support for MT8196 eDP PHY AngeloGioacchino Del Regno
2026-07-01 12:20 ` AngeloGioacchino Del Regno
2026-07-01 13:01 ` sashiko-bot
2026-07-01 13:01 ` sashiko-bot
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=20260701130223.CF9691F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--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.