Re: [PATCH v4 3/3] drm/exynos: remove simplefb nodes before init

[sashiko-bot@kernel.org]

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

New issues:
- [Medium] Incorrect error handling path for aperture_remove_all_conflicting_devices() triggers WARN_ON() storms by attempting to unbind unbound components.

Pre-existing issues:
- [Medium] The setup loop for `possible_clones` iterates over an empty `encoder_list` because encoders are not registered until sub-components are bound.
--

--- Patch [3]: [PATCH v4 3/3] drm/exynos: remove simplefb nodes before init ---
commit 9e7932152628258cc8174577476729d0609085e6
Author: Kaustabh Chakraborty <kauschluss@disroot.org>

drm/exynos: remove simplefb nodes before init

This commit uses aperture_remove_all_conflicting_devices() to remove
simple-framebuffer devices before initializing the DSI and FIMD/DECON stack.
This ensures memory regions do not overlap during display transitions.

> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 9ee30086879f9..e05e520449edc 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
[ ... ]
> @@ -268,6 +269,11 @@ static int exynos_drm_bind(struct device *dev)
>  	list_for_each_entry(encoder, &drm->mode_config.encoder_list, head)
>  		encoder->possible_clones = clone_mask;
>  

[Severity: Medium]
This is a pre-existing issue, but does this loop successfully find any
encoders?

In the Exynos DRM architecture, encoders are registered by sub-components
during their bind phase, which is triggered by component_bind_all().
Since this setup block is placed before component_bind_all(), the
encoder_list is always empty, making this dead code and leaving
possible_clones unconfigured for all encoders.

> +	/* Remove existing devices which own the framebuffer memory. */
> +	ret = aperture_remove_all_conflicting_devices(exynos_drm_driver.name);
> +	if (ret)
> +		goto err_unbind_all;
                ^^^^

[Severity: Medium]
Will this error path trigger WARN_ON() storms?

If aperture_remove_all_conflicting_devices() fails, the code jumps to
err_unbind_all, which executes component_unbind_all().

Since component_bind_all() has not yet been executed, all matched components
have component->bound == false. For each component, component_unbind()
evaluates WARN_ON(!component->bound) and triggers a kernel warning stack
trace.

Could this jump to err_mode_config_cleanup instead, similar to the failure
path for component_bind_all()?

> +
>  	/* Try to bind all sub drivers. */
>  	ret = component_bind_all(drm->dev, drm);
>  	if (ret)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260809-exynos-dsim-fixes-v4-0-ca67c51e61b7@disroot.org?part=3