Re: [PATCH 19/37] drm/bridge: samsung-dsim: move drm_bridge_add() call to probe

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Moving drm_bridge_add() to probe() breaks probe deferral, causing a permanent -EINVAL failure.
- [Medium] Lockless data race on bridge state and next_bridge pointer when the panel attaches asynchronously.
--

commit 8b9a88707049c09bf2d0cddc2aeab67e8c2ea0b4
Author: Luca Ceresoli <luca.ceresoli@bootlin.com>

drm/bridge: samsung-dsim: move drm_bridge_add() call to probe

This commit moves the drm_bridge_add() call from the DSI host attach
callback to the probe function to allow the DRM card to populate even
without a connected DSI device.

> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
[ ... ]
> @@ -2222,6 +2217,8 @@ int samsung_dsim_probe(struct platform_device *pdev)
>  			goto err_disable_runtime;
>  	}
>  
> +	drm_bridge_add(&dsi->bridge);
> +
>  	return 0;

Does moving drm_bridge_add() to the probe function break probe deferral?

By registering the DRM bridge here, the bridge becomes immediately available
to the DRM master (like imx-lcdif) before the downstream DSI panel has probed.
When the DRM master probes, it finds the bridge and calls drm_bridge_attach().
This routes to samsung_dsim_attach(), which unconditionally attempts to attach
dsi->bridge.next_bridge. 

Because the panel hasn't attached yet, next_bridge is NULL. Passing a NULL
bridge to drm_bridge_attach() returns -EINVAL. This seems to cause the
display controller's probe to fail permanently instead of properly deferring
via -EPROBE_DEFER.

I noticed this is resolved later in the series by commit b9977e0ebaa4d
(drm/bridge: samsung-dsim: attach: return -EPROBE_DEFER is next bridge not yet
available), but it introduces a regression at this point in the tree.

Also, does this introduce a data race on the bridge state when the panel
attaches asynchronously?

Since the bridge is now exposed to the global bridge_list early, the DRM core
or master could access it while the downstream panel is still probing. The
dsi->bridge.next_bridge pointer and configurations like lanes, format, and
mode_flags are updated later in samsung_dsim_host_attach() without acquiring
any locks. 

Is it possible for atomic callbacks or the DRM master's probe to read a
partially-updated next_bridge pointer or uninitialized configuration state
during this window?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-drm-bridge-hotplug-v1-0-45e2bdb3dfb4@bootlin.com?part=19