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