Re: [PATCH 2/3] drm/panel: raydium-rm68200: Use mipi_dsi_*_multi() functions

[sashiko-bot@kernel.org]

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 <hungen3108@gmail.com>

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/20261014135028.1438841-1-hungen3108@gmail.com?part=2