Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:
- [Medium] drm/panel: resource leak in rm68200_prepare() on error path
--

commit c6e53b42c5c0d14746a1b84a032e5221f6e17711
Author: Hsieh Hung-En <[email protected]>

drm/panel: raydium-rm68200: Use mipi_dsi_*_multi() functions

This patch replaces the deprecated MIPI DSI DCS helpers with their multi
variants in the raydium-rm68200 panel driver. It utilizes mipi_dsi_msleep to
skip delays after failed commands and defers error return to the end of the
prepare sequence.

> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c 
> b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
> index c535dc931903e..971d075bb0601 100644
> --- a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c

[ ... ]

> @@ -258,6 +256,7 @@ static int rm68200_prepare(struct drm_panel *panel)
>  {
>       struct rm68200 *ctx = panel_to_rm68200(panel);
>       struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> +     struct mipi_dsi_multi_context dsi_ctx = { .dsi = dsi };
>       int ret;
>  
>       ret = regulator_enable(ctx->supply);

[ ... ]

>       rm68200_init_sequence(ctx);
>  
> -     ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> -     if (ret)
> -             return ret;
> +     mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
>  
> -     msleep(125);
> +     mipi_dsi_msleep(&dsi_ctx, 125);
>  
> -     ret = mipi_dsi_dcs_set_display_on(dsi);
> -     if (ret)
> -             return ret;
> +     mipi_dsi_dcs_set_display_on_multi(&dsi_ctx);
>  
> -     msleep(20);
> +     mipi_dsi_msleep(&dsi_ctx, 20);
>  
> -     return 0;
> +     return dsi_ctx.accum_err;

[Severity: Medium]
Does this error path leak the regulator reference and leave the reset GPIO
asserted?

If a DCS command fails during rm68200_prepare(), the function returns
dsi_ctx.accum_err. Because drm_panel_prepare() in the DRM core does not set
panel->prepared = true on failure, subsequent calls to drm_panel_unprepare()
return early without executing rm68200_unprepare().

If that happens, is there anything to disable ctx->supply or reset the
GPIO?

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=2

Reply via email to