Re: [PATCH 3/3] drm/panel: raydium-rm68200: Use multi-context helpers for init sequence

[sashiko-bot@kernel.org]

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

commit 43be4887f342d01dc5322111059b764933197c3c
Author: Hsieh Hung-En <hungen3108@gmail.com>

drm/panel: raydium-rm68200: Use multi-context helpers for init sequence
    
The commit replaces the custom DCS write helpers with the multi-context
helpers mipi_dsi_dcs_write_seq_multi() and mipi_dsi_dcs_write_var_seq_multi().
It also shares the multi-context with prepare() so that errors are
propagated and subsequent commands are skipped after a failure.

> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
> index c535dc931903e..a01b2db55c7f0 100644
> --- a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
[ ... ]
> @@ -273,21 +248,17 @@ static int rm68200_prepare(struct drm_panel *panel)
>  		msleep(100);
>  	}
>  
> -	rm68200_init_sequence(ctx);
> +	rm68200_init_sequence(&dsi_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 code leak the regulator enable count?

rm68200_prepare() enables the ctx->supply regulator and configures
ctx->reset_gpio at the beginning of the function.

The patch changes the execution flow so that if any of the DCS commands fail,
their error is recorded in dsi_ctx.accum_err. The function then returns
dsi_ctx.accum_err directly, without disabling the regulator or asserting the
reset GPIO.

If funcs->prepare() returns an error, the DRM panel framework does not mark
the panel as prepared and will never call funcs->unprepare() to clean up.

Consequently, the regulator enable count would be permanently unbalanced and
the hardware would remain partially powered. While this leak existed
previously for the sleep and display commands, this patch modifies the error
return paths and makes it significantly more likely to trigger by now
aborting on any initialization sequence error as well.

Could an error unwind path be added to clean up the regulator and GPIO?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014135028.1438841-1-hungen3108@gmail.com?part=3