Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>
Cc: dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
	robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v3 09/11] drm/mediatek: mtk_dp: Add support for HotPlug Detection in DP AUX
Date: Thu, 09 Jul 2026 10:49:08 +0000	[thread overview]
Message-ID: <20260709104908.EE1E51F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260709103431.46616-10-angelogioacchino.delregno@collabora.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing conditional logic when unmasking TRANS HPD interrupts leads to potential interrupt storm lockup.
- [Medium] Missing register offset addition (`legacy_regoff`) in `regmap_read_poll_timeout` for `MTK_DP_AUX_P0_364C`.
--

--- Patch [9]: [PATCH v3 09/11] drm/mediatek: mtk_dp: Add support for HotPlug Detection in DP AUX ---
commit 7b18e9e5242c5a51686ac5bc28f9baba9e41f72f
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

drm/mediatek: mtk_dp: Add support for HotPlug Detection in DP AUX

Newer MediaTek DisplayPort IPs can use the AUX to perform hotplug detection
(HPD) without having to power up the entire eDP or DP IP. This commit enables
support for configuring and performing HPD in AUX and checks the correct HPD
strategy with a new platform data variable.

> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
[ ... ]
> @@ -1062,8 +1086,28 @@ static u32 mtk_dp_hwirq_get_clear(struct mtk_dp *mtk_dp)
>  	return irq_status;
>  }
>  
> +static inline u32 mtk_dp_hwirq_get_clear(struct mtk_dp *mtk_dp)
> +{
> +	if (mtk_dp->data->aux_hpd_supported)
> +		return mtk_dp_aux_hwirq_get_clear(mtk_dp);
> +
> +	return mtk_dp_trans_hwirq_get_clear(mtk_dp);
> +}
> +
>  static void mtk_dp_hwirq_enable(struct mtk_dp *mtk_dp, bool enable)
>  {
> +	u32 mask, val;
> +
> +	/* Valid only for SoCs with working AUX HPD, this register is ignored on the others */
> +	if (enable) {
> +		mask = HPD_CONNECT_EVENT | HPD_INTERRUPT_EVENT | HPD_DISCONNECT_EVENT;
> +		val = 0;
> +	} else {
> +		mask = DP_TX_AUX_INT_MASK;
> +		val = DP_TX_AUX_INT_MASK;
> +	}
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TX_AUX_INT_MASKING, val, mask);
> +
>  	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3418,
>  			   enable ? 0 :
>  			   IRQ_MASK_DP_TRANS_P0_DISC_IRQ |
>  			   IRQ_MASK_DP_TRANS_P0_CONN_IRQ |
>  			   IRQ_MASK_DP_TRANS_P0_INT_IRQ,
>  			   IRQ_MASK_DP_TRANS_P0_MASK);
>  }

[Severity: High]
Does this unconditionally unmask the TRANS HPD interrupts even when
aux_hpd_supported is true?

If the TRANS hardware asserts an HPD interrupt (such as line noise),
mtk_dp_hwirq_get_clear() will completely skip reading and clearing the
TRANS HPD interrupt status because aux_hpd_supported is true.

Since the bit is never cleared, irq_status will be 0 in mtk_dp_hpd_event(),
which then returns IRQ_HANDLED:

	if (!irq_status)
		return IRQ_HANDLED;

Will returning IRQ_HANDLED defeat the kernel's spurious interrupt
detector and lead to an infinite interrupt storm lockup?

[ ... ]
> @@ -2113,10 +2191,15 @@ static int mtk_dp_wait_hpd_asserted(struct drm_dp_aux *mtk_aux, unsigned long wa
>  	u32 val;
>  	int ret;
>  
> -	ret = regmap_read_poll_timeout(mtk_dp->regs,
> -				       MTK_DP_TRANS_P0_3414 + mtk_dp->legacy_regoff,
> -				       val, !!(val & HPD_DB_DP_TRANS_P0_MASK),
> -				       wait_us / 100, wait_us);
> +	if (mtk_dp->data->aux_hpd_supported)
> +		ret = regmap_read_poll_timeout(mtk_dp->regs, MTK_DP_AUX_P0_364C,
> +					       val, !!(val & HPD_STATUS_DP_AUX_TX_P0_MASK),
> +					       wait_us / 100, wait_us);

[Severity: Medium]
Is this missing the legacy_regoff addition?

The original code and the else branch both add mtk_dp->legacy_regoff
when calling regmap_read_poll_timeout().

If an SoC ever uses a non-zero legacy_regoff while supporting AUX HPD,
could this read from the wrong hardware register address?

> +	else
> +		ret = regmap_read_poll_timeout(mtk_dp->regs,
> +					       MTK_DP_TRANS_P0_3414 + mtk_dp->legacy_regoff,
> +					       val, !!(val & HPD_DB_DP_TRANS_P0_MASK),
> +					       wait_us / 100, wait_us);
>  	if (ret) {
>  		mtk_dp->train_info.cable_plugged_in = false;
>  		return ret;

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

  reply	other threads:[~2026-07-09 10:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 10:34 [PATCH v3 00/11] drm: MediaTek DisplayPort cleanups and MT8196 eDP AngeloGioacchino Del Regno
2026-07-09 10:34 ` [PATCH v3 01/11] dt-bindings: display: mediatek: dp: Deprecate nvmem efuse data AngeloGioacchino Del Regno
2026-07-09 10:34 ` [PATCH v3 02/11] dt-bindings: display: mediatek: dp: Add compatible for MT8196 eDP AngeloGioacchino Del Regno
2026-07-09 10:34 ` [PATCH v3 03/11] drm/mediatek: mtk_dp: Fix hdmi codec and phy driver unregistration AngeloGioacchino Del Regno
2026-07-09 10:46   ` sashiko-bot
2026-07-09 11:10     ` AngeloGioacchino Del Regno
2026-07-09 10:34 ` [PATCH v3 04/11] drm/mediatek: mtk_dp: Clarify SMC eDP/DP video unmute commands AngeloGioacchino Del Regno
2026-07-09 10:34 ` [PATCH v3 05/11] drm/mediatek: mtk_dp: Rework register offsets for proper PHY usage AngeloGioacchino Del Regno
2026-07-09 10:34 ` [PATCH v3 06/11] drm/mediatek: mtk_dp: Use PHY API for PHY power sequences AngeloGioacchino Del Regno
2026-07-09 11:00   ` sashiko-bot
2026-07-09 10:34 ` [PATCH v3 07/11] drm/mediatek: mtk_dp: Add support for PHY from devicetree AngeloGioacchino Del Regno
2026-07-09 10:55   ` sashiko-bot
2026-07-09 10:34 ` [PATCH v3 08/11] drm/mediatek: mtk_dp: Move max link rate to SoC specific data AngeloGioacchino Del Regno
2026-07-09 10:47   ` sashiko-bot
2026-07-09 10:34 ` [PATCH v3 09/11] drm/mediatek: mtk_dp: Add support for HotPlug Detection in DP AUX AngeloGioacchino Del Regno
2026-07-09 10:49   ` sashiko-bot [this message]
2026-07-09 10:34 ` [PATCH v3 10/11] drm/mediatek: mtk_dp: Add support for eDP1.5 IPs and MT8196 SoC AngeloGioacchino Del Regno
2026-07-09 10:51   ` sashiko-bot
2026-07-09 10:34 ` [PATCH v3 11/11] drm/mediatek: mtk_dp: Clarify XTAL freq and Debounce registers AngeloGioacchino Del Regno
2026-07-09 10:42   ` 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=20260709104908.EE1E51F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox