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

[Dmitry Baryshkov]

On Thu, May 14, 2026 at 10:44:23AM +0000, sashiko-bot at kernel.org wrote:
> 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:

Only if the DP isn't configured at the moment of 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.

Because it's all about the pending events. If there is no HPD set, then
there is no point in processing IRQ_HPD events too (please correct me if
I'm wrong).

> 
> 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
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

-- 
With best wishes
Dmitry