From: sashiko-bot@kernel.org
To: "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>
Cc: conor+dt@kernel.org, dri-devel@lists.freedesktop.org,
robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v4 12/12] drm/mediatek: mtk_dp: Clarify XTAL freq and Debounce registers
Date: Thu, 09 Jul 2026 11:57:49 +0000 [thread overview]
Message-ID: <20260709115749.CA0B41F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260709113148.49090-13-angelogioacchino.delregno@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch silently fixes a pre-existing double-shift bug that was incorrectly writing 0 to the HPD interrupt debounce thresholds. This alters the hardware state, contradicting the commit message's claim that its 'only purpose [is] increasing human readability'.
--
--- Patch [12]: [PATCH v4 12/12] drm/mediatek: mtk_dp: Clarify XTAL freq and Debounce registers ---
commit 947b13de5fec9b2788067fcdae3f6c00732e0060
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
drm/mediatek: mtk_dp: Clarify XTAL freq and Debounce registers
This patch clarifies the meaning of the sub-fields in the crystal frequency
and transmitter interrupt debounce registers for increased human readability.
> Clarify the meaning of the sub-fields in the crystal frequency and
> transmitter interrupt debounce registers, with the only purpose of
> increasing human readability.
[ ... ]
> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> @@ -1260,28 +1266,29 @@ static void mtk_dp_initialize_aux_hpd_detect_settings(struct mtk_dp *mtk_dp)
>
> static void mtk_dp_initialize_hpd_detect_settings(struct mtk_dp *mtk_dp)
> {
> - u32 val;
> -
> /* Mask AUX TOP interrupt, as this uses transmitter for HPD */
> mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_IRQ_MASK,
> AUX_TOP_IRQ_MSK, AUX_TOP_IRQ_MSK);
>
> - /* Debounce threshold */
> + /* Set Hotplug debounce threshold time: xtal_period * deb_thd */
> mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> 8, HPD_DEB_THD_DP_TRANS_P0_MASK);
>
> - val = (HPD_INT_THD_DP_TRANS_P0_LOWER_500US |
> - HPD_INT_THD_DP_TRANS_P0_UPPER_1100US) << 4;
> - mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> - val, HPD_INT_THD_DP_TRANS_P0_MASK);
> -
> /*
> - * Connect threshold 1.5ms + 5 x 0.1ms = 2ms
> - * Disconnect threshold 1.5ms + 5 x 0.1ms = 2ms
> + * Set interrupt debounce threshold time
> + * VAL | 0 1 2 3 INT_THD
> + * Low | 100 300 500 700 uS
> + * High | 700 900 1100 1300 uS
> */
> - val = (5 << 8) | (5 << 12);
> mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> - val,
> + FIELD_PREP_CONST(HPD_INT_LOW_THD_DP_TRANS_P0_MASK, 2) |
> + FIELD_PREP_CONST(HPD_INT_HIGH_THD_DP_TRANS_P0_MASK, 2),
> + HPD_INT_THD_DP_TRANS_P0_MASK);
[Severity: Medium]
Does this patch silently fix a functional bug rather than just improving
readability?
In the original code, the LOWER_500US and UPPER_1100US macros were already
shifted by 4 and 6 respectively. Applying << 4 on top of them resulted in a
double shift, making val equal to 0xA00. When that was masked with
HPD_INT_THD_DP_TRANS_P0_MASK (which is 0xF0), it evaluated to 0, incorrectly
programming the hardware.
The new code using FIELD_PREP_CONST calculates 0xA0, correctly applying the
intended 500/1100uS thresholds.
Since the commit message states this has the only purpose of increasing human
readability, could this functional fix be overlooked for stable backports?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260709113148.49090-1-angelogioacchino.delregno@collabora.com?part=12
prev parent reply other threads:[~2026-07-09 11:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 11:31 [PATCH v4 00/12] drm: MediaTek DisplayPort cleanups and MT8196 eDP AngeloGioacchino Del Regno
2026-07-09 11:31 ` [PATCH v4 01/12] dt-bindings: display: mediatek: dp: Deprecate nvmem efuse data AngeloGioacchino Del Regno
2026-07-11 15:08 ` Krzysztof Kozlowski
2026-07-09 11:31 ` [PATCH v4 02/12] dt-bindings: display: mediatek: dp: Add compatible for MT8196 eDP AngeloGioacchino Del Regno
2026-07-11 15:08 ` Krzysztof Kozlowski
2026-07-09 11:31 ` [PATCH v4 03/12] drm/mediatek: mtk_dp: Call pm_runtime_put_sync() in removal path AngeloGioacchino Del Regno
2026-07-09 11:42 ` sashiko-bot
2026-07-09 11:31 ` [PATCH v4 04/12] drm/mediatek: mtk_dp: Fix hdmi codec and phy driver unregistration AngeloGioacchino Del Regno
2026-07-09 11:48 ` sashiko-bot
2026-07-09 11:31 ` [PATCH v4 05/12] drm/mediatek: mtk_dp: Clarify SMC eDP/DP video unmute commands AngeloGioacchino Del Regno
2026-07-09 11:31 ` [PATCH v4 06/12] drm/mediatek: mtk_dp: Rework register offsets for proper PHY usage AngeloGioacchino Del Regno
2026-07-09 11:31 ` [PATCH v4 07/12] drm/mediatek: mtk_dp: Use PHY API for PHY power sequences AngeloGioacchino Del Regno
2026-07-09 11:53 ` sashiko-bot
2026-07-09 11:31 ` [PATCH v4 08/12] drm/mediatek: mtk_dp: Add support for PHY from devicetree AngeloGioacchino Del Regno
2026-07-09 11:31 ` [PATCH v4 09/12] drm/mediatek: mtk_dp: Move max link rate to SoC specific data AngeloGioacchino Del Regno
2026-07-09 11:53 ` sashiko-bot
2026-07-09 11:31 ` [PATCH v4 10/12] drm/mediatek: mtk_dp: Add support for HotPlug Detection in DP AUX AngeloGioacchino Del Regno
2026-07-09 12:00 ` sashiko-bot
2026-07-09 12:05 ` AngeloGioacchino Del Regno
2026-07-09 11:31 ` [PATCH v4 11/12] drm/mediatek: mtk_dp: Add support for eDP1.5 IPs and MT8196 SoC AngeloGioacchino Del Regno
2026-07-09 12:11 ` sashiko-bot
2026-07-09 12:17 ` AngeloGioacchino Del Regno
2026-07-09 11:31 ` [PATCH v4 12/12] drm/mediatek: mtk_dp: Clarify XTAL freq and Debounce registers AngeloGioacchino Del Regno
2026-07-09 11:57 ` sashiko-bot [this message]
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=20260709115749.CA0B41F000E9@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=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.