[PATCH RESEND v3 1/6] drm/connector: report IRQ_HPD events to drm_connector_oob_hotplug_event()

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] IRQ_HPD events are silently dropped if a status update triggers a reconfiguration while the HPD state remains unchanged.
- [High] Deferred events in `dp_altmode_configured()` unconditionally report the display as connected and leak stale `pending_irq_hpd` / `pending_hpd` state.
--

commit 53d82f9a5286a8fa5530ca1be94f61940637586b
Author: Dmitry Baryshkov <dmitry.baryshkov at oss.qualcomm.com>

drm/connector: report IRQ_HPD events to drm_connector_oob_hotplug_event()

This commit extends the drm_connector_oob_hotplug_event() interface to report
DisplayPort irq events. These events are now forwarded through the alt mode
messages to the sink drivers to support multi-stream transport handling.

> diff --git a/drivers/usb/typec/altmodes/displayport.c b/drivers/usb/typec/altmodes/displayport.c
> index 35d9c30869900..7182a8e2e7101 100644
> --- a/drivers/usb/typec/altmodes/displayport.c
> +++ b/drivers/usb/typec/altmodes/displayport.c
[ ... ]
> @@ -212,7 +214,10 @@ static int dp_altmode_configured(struct dp_altmode *dp)
>  	 */
>  	if (dp->pending_hpd) {
>  		drm_connector_oob_hotplug_event(dp->connector_fwnode,
> -						connector_status_connected);
> +						connector_status_connected,
> +						dp->pending_irq_hpd ?
> +						DRM_CONNECTOR_DP_IRQ_HPD :
> +						DRM_CONNECTOR_NO_EXTRA_STATUS);

Are irq events silently dropped if a status update triggers a
reconfiguration while the hotplug detect state remains unchanged?

Looking at dp_altmode_status_update(), if a status update requires
reconfiguration, the code attempts to buffer the event:

	if (!(con & DP_CONF_CURRENTLY(dp->data.conf))) {
		ret = dp_altmode_configure(dp, con);
		if (!ret) {
			dp->state = dp->plug_prime ? DP_STATE_CONFIGURE_PRIME :
						     DP_STATE_CONFIGURE;
			if (dp->hpd != hpd) {
				dp->hpd = hpd;
				dp->pending_hpd = true;
			}
			if (dp->hpd && dp->pending_hpd && irq_hpd)
				dp->pending_irq_hpd = true;
		}
	}

It only sets dp->pending_hpd = true if the hotplug detect state has toggled. If
it remains unchanged, dp->pending_hpd stays false. This prevents
dp->pending_irq_hpd from being set even if irq_hpd is true.

Could this cause DisplayPort irq events that arrive concurrently with a
configuration change to be lost, preventing downstream multi-stream transport
topology updates and link training?

Additionally, does this deferred event unconditionally report the display as
connected and leak stale state?

If multiple status update messages arrive before configuration
completes, dp->hpd can transition to false while dp->pending_hpd and
dp->pending_irq_hpd remain true.

Similarly, if the alt mode is exited via CMD_EXIT_MODE while
dp->pending_hpd is true, these pending flags are never cleared.

Will this cause the drm driver to receive a spurious connection event and
irq when configuration completes or when the alt mode is later re-entered?

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