Re: [PATCH v2 26/37] drm/exynos: mic: Switch to atomic bridge callbacks

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The result of `exynos_drm_crtc_get_by_type()` is dereferenced directly without an error pointer check, leading to a kernel panic.
--

--- Patch [26]: [PATCH v2 26/37] drm/exynos: mic: Switch to atomic bridge callbacks ---
commit 1ac627a57ce38903ca33c5eb6829642986ddaad3
Author: Maxime Ripard <mripard@kernel.org>

drm/exynos: mic: Switch to atomic bridge callbacks

This commit switches the mic bridge driver to use atomic pre_enable and
post_disable callbacks instead of the legacy non-atomic ones. It also adds
the necessary atomic state handlers to support the transition in the DRM
bridge core.

> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index e68c954ec3e61..3069f958137f5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c

[ ... ]

> @@ -295,9 +298,12 @@ static void mic_pre_enable(struct drm_bridge *bridge)
>  }
>  
>  static const struct drm_bridge_funcs mic_bridge_funcs = {
> -	.post_disable = mic_post_disable,
> +	.atomic_create_state = drm_atomic_helper_bridge_create_state,
> +	.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> +	.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> +	.atomic_post_disable = mic_post_disable,
>  	.mode_set = mic_mode_set,
> -	.pre_enable = mic_pre_enable,
> +	.atomic_pre_enable = mic_pre_enable,
>  };
>  
>  static int exynos_mic_bind(struct device *dev, struct device *master,
>  			   void *data)

[Severity: High]
This is a pre-existing issue, but can this function trigger a kernel
panic on invalid or incomplete devicetree configurations?

Looking at exynos_mic_bind(), exynos_drm_crtc_get_by_type() can return
an error pointer like ERR_PTR(-ENODEV) if the LCD CRTC component is
not found:

	struct exynos_drm_crtc *crtc = exynos_drm_crtc_get_by_type(drm_dev,
						       EXYNOS_DISPLAY_TYPE_LCD);
	struct drm_encoder *e, *encoder = NULL;

	drm_for_each_encoder(e, drm_dev)
		if (e->possible_crtcs == drm_crtc_mask(&crtc->base))
			encoder = e;

Since the code passes &crtc->base to drm_crtc_mask() without checking
if crtc is an error pointer first, and drm_crtc_mask() dereferences it to
access crtc->index, won't this cause a panic during probe if the component
is missing?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707-drm-all-atomic-bridges-v2-0-21d03cbca446@kernel.org?part=26