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 <[email protected]>

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/[email protected]?part=3

Reply via email to