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