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

Pre-existing issues:
- [High] Sleeping functions (mutex_lock and usleep_range) are invoked from 
within the DRM bridge atomic enable/disable paths, violating atomic context 
constraints.
--

--- Patch [17]: [PATCH v11 17/21] drm/bridge: synopsys: dw-dp: Drop useless 
reservation of first slot ---
commit 8eeeddc14d0ae1c89dc44b8a4cd95896d24d3082
Author: Sebastian Reichel <[email protected]>

drm/bridge: synopsys: dw-dp: Drop useless reservation of first slot

This patch removes the reservation of the first SDP slot in the atomic
enable path because it potentially races with audio SDP reservation. The
author mentions it is unnecessary or leftover development code, and that
slot 0 works fine without being reserved.

> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> index 31495a813e408..d8682ccdfec87 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> @@ -1713,9 +1713,6 @@ static void dw_dp_bridge_atomic_enable(struct 
> drm_bridge *bridge,
>               return;
>       }
>  
> -     scoped_guard(mutex, &dp->sdp_lock)
> -             set_bit(0, dp->sdp_reg_bank);
> -
>       ret = dw_dp_link_enable(dp);

[Severity: High]
This isn't a bug introduced by this patch, but this function executes during the
DRM atomic commit sequence where sleeping is strictly forbidden. While this
patch removes one instance of mutex acquisition, the remaining atomic enable
and disable paths still contain sleeping functions.

For example, dw_dp_link_enable() eventually calls dw_dp_link_train_fast() which
sleeps:

drivers/gpu/drm/bridge/synopsys/dw-dp.c:dw_dp_link_train_fast() {
    ...
    usleep_range(500, 1000);
    ...
}

Other functions in the atomic path, such as dw_dp_send_sdp() and
dw_dp_bridge_atomic_disable(), also acquire the same mutex:

drivers/gpu/drm/bridge/synopsys/dw-dp.c:dw_dp_bridge_atomic_disable() {
    ...
    scoped_guard(mutex, &dp->sdp_lock)
    ...
}

Can these remaining sleeping functions cause kernel warnings or deadlocks during
standard display modeset operations?

>       if (ret < 0) {
>               dev_err(dp->dev, "failed to enable link: %d\n", ret);

-- 
Sashiko AI review · 
https://sashiko.dev/#/patchset/20260806-synopsys-dw-dp-improvements-v11-0-0d508505f...@collabora.com?part=17

Reply via email to