Re: [PATCH RESEND v3 4/6] drm/msm: dp: handle the IRQ_HPD events reported by USB-C - sashiko-bot

From: sashiko-bot@kernel.org
To: "Dmitry Baryshkov" <dmitry.baryshkov@oss.qualcomm.com>
Cc: neil.armstrong@linaro.org, linux-amlogic@lists.infradead.org
Subject: Re: [PATCH RESEND v3 4/6] drm/msm: dp: handle the IRQ_HPD events reported by USB-C
Date: Thu, 14 May 2026 12:06:00 +0000	[thread overview]
Message-ID: <20260514120601.54231C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <20260513-hpd-irq-events-v3-4-086857017f16@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unbounded enqueueing of EV_IRQ_HPD_INT events can exhaust the small event queue, causing critical hotplug events to be dropped and deadlocking the DP driver.
--

commit 03d05144a4cd57cfc0c6a88377ee764f4224e2b4
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>

drm/msm: dp: handle the IRQ_HPD events reported by USB-C

Let the MSM DisplayPort driver properly track and handle IRQ_HPD
delivered over the OOB events (e.g. from the USB-C AltMode handler).

> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -1800,4 +1800,7 @@ void msm_dp_bridge_hpd_notify(struct drm_bridge *bridge,
>  		msm_dp_add_event(dp, EV_HPD_PLUG_INT, 0, 0);
>  	else if (msm_dp_display->link_ready && status == connector_status_disconnected)
>  		msm_dp_add_event(dp, EV_HPD_UNPLUG_INT, 0, 0);
> +
> +	if (extra_status == DRM_CONNECTOR_DP_IRQ_HPD)
> +		msm_dp_add_event(dp, EV_IRQ_HPD_INT, 0, 0);

Could this unbounded enqueueing of EV_IRQ_HPD_INT events exhaust the event
queue?

The MSM DP driver's event queue has a fixed capacity of 7 items, as
DP_EVENT_Q_MAX is 8. Adding EV_IRQ_HPD_INT events directly from out-of-band
messages without deduplication could fill the queue if multiple events arrive
quickly.

If the display state is ST_MAINLINK_READY or ST_DISCONNECT_PENDING,
msm_dp_irq_hpd_handle() defers the event by re-adding it to the queue with
delay = 1.

The hpd_event_thread handles delay = 1 events by converting them to delay = 0,
placing them back in the queue, and sleeping for 100ms before calling
msm_dp_irq_hpd_handle() again. This causes the event to cycle endlessly,
perpetually occupying a slot.

If a sink sends 7 rapid IRQ_HPD signals while the driver is parked in
ST_MAINLINK_READY, the queue might become entirely full with 7 cycling,
unconsumed events.

If the queue is full, would critical events like EV_HPD_UNPLUG_INT be lost
since msm_dp_add_event() returns -EPERM? Losing the unplug event could trap
the DRM framework in a connected state despite physical disconnection.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513-hpd-irq-events-v3-0-086857017f16@oss.qualcomm.com?part=4

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic