Re: [PATCH v4 05/10] drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing Workqueue Cancellation / Use-After-Free in teardown path
--

--- Patch [5]: [PATCH v4 05/10] drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD ---
commit 27d73c3f273597742127e6851884d387b3ffe886
Author: Sebastian Reichel <sebastian.reichel@collabora.com>

drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD

This patch adds support for USB-C DP AltMode out-of-band hotplug handling
by allowing platform-specific drivers to implement HPD software
configuration and selection.

> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> index 0e8ecd73a0002..8eb2699dc7ab0 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c

[ ... ]

> @@ -2052,6 +2086,10 @@ struct dw_dp *dw_dp_probe(struct platform_device *pdev, const struct dw_dp_plat_
>  
>  	dp->dev = dev;
>  	dp->pixel_mode = plat_data->pixel_mode;
> +
> +	dp->plat_data.hpd_sw_sel = plat_data->hpd_sw_sel;
> +	dp->plat_data.hpd_sw_cfg = plat_data->hpd_sw_cfg;
> +	dp->plat_data.data = plat_data->data;
>  	dp->plat_data.max_link_rate = plat_data->max_link_rate;
>  
>  	mutex_init(&dp->irq_lock);

[Severity: High]
This is a pre-existing issue, but is there a missing workqueue cancellation
in the driver teardown path?

In dw_dp_probe(), the driver initializes a work item for hotplug detection
shortly after the modified code block:

    INIT_WORK(&dp->hpd_work, dw_dp_hpd_work);

However, looking at dw_dp_unbind(), the work is never canceled:

    void dw_dp_unbind(struct dw_dp *dp)
    {
        disable_irq(dp->irq);
        phy_exit(dp->phy);
        drm_bridge_put(dp->next_bridge);
        drm_dp_aux_unregister(&dp->aux);
        drm_bridge_remove(&dp->bridge);
    }

Since the dp structure is automatically freed by devres after the remove
callback completes, could this result in a use-after-free if the IRQ
handler schedules the work right before unbound is called, and the work
executes after the dp structure is deallocated? 

Would it make sense to add a cancel_work_sync(&dp->hpd_work) call to the
teardown path to ensure the work item finishes safely?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-synopsys-dw-dp-improvements-v4-0-f0f4a4ede712@collabora.com?part=5