[PATCH v7 18/23] drm: bridge: dw_hdmi: Drop call to drm_bridge_hpd_notify()

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing `drm_bridge_hpd_notify()` violates the `DRM_BRIDGE_OP_HPD` contract and replaces targeted bridge HPD notification with an inefficient global device poll.
--

commit f2225f0de66ea8205ddbd49531c0c402dab0c72b
Author: Jonas Karlman <jonas at kwiboo.se>

drm: bridge: dw_hdmi: Drop call to drm_bridge_hpd_notify()

This commit removes the call to drm_bridge_hpd_notify() from the dw_hdmi
hotplug interrupt handler. It relies instead solely on
drm_helper_hpd_irq_event() to trigger hotplug events in order to prevent
multiple hotplug uevents and redundant modeset probes.

> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 5dacb8a99715b..8afc9d2401214 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -3101,10 +3101,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>  			status == connector_status_connected ?
>  			"plugin" : "plugout");
>  
> -		if (hdmi->bridge.dev) {
> +		if (hdmi->bridge.dev)
>  			drm_helper_hpd_irq_event(hdmi->bridge.dev);
> -			drm_bridge_hpd_notify(&hdmi->bridge, status);
> -		}

Does removing the drm_bridge_hpd_notify() call violate the DRM_BRIDGE_OP_HPD
API contract?

The dw_hdmi driver is registered with the DRM_BRIDGE_OP_HPD flag, which
typically requires the driver to call drm_bridge_hpd_notify() on status
changes so that registered callbacks like drm_bridge_connector_hpd_cb()
are properly invoked.

By relying solely on drm_helper_hpd_irq_event(), doesn't this replace the
targeted bridge HPD notification with a global device poll?

Looking at drm_helper_hpd_irq_event() in drm_probe_helper.c, it acquires
dev->mode_config.mutex and iterates over all connectors on the DRM device,
calling their detect() functions synchronously. In multi-display systems
(for example, HDMI alongside eDP or DSI), will an HDMI hotplug interrupt
now trigger slow DDC/I2C/AUX probes on those completely unrelated connectors?

While later patches or discussions might address using delayed_work to debounce
hotplug events to avoid mutex deadlocks, could the driver resolve those locking
issues without bypassing the bridge framework's targeted notification mechanism
and forcing an inefficient global poll?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518180206.2480119-1-jonas@kwiboo.se?part=18