Re: [PATCH v5 2/2] drm: panel: add support for the Renesas R63419 based dual-DSI video mode Display Panels

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Uninitialized stack variable `dsi_ctx` causes undefined behavior in DSI initialization
- [High] Incorrect MIPI DCS initialization sequence (Set Display On before Exit Sleep Mode)
- [High] Race condition due to panel registration before DSI hardware is attached
--

commit 1aa27fde3d1fe4c1d08cfa9a63d3e7e28912831f
Author: KancyJoe <kancy2333@outlook.com>

drm: panel: add support for the Renesas R63419 based dual-DSI video mode Display Panels

Implement support for the Renesas 63419 based dual-DSI video mode
Display Panels found in the Ayaneo gaming handled devices.

> diff --git a/drivers/gpu/drm/panel/panel-renesas-r63419.c b/drivers/gpu/drm/panel/panel-renesas-r63419.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-renesas-r63419.c

[ ... ]

> +static int renesas_r63419_on(struct renesas_r63419_panel *ctx)
> +{
> +	struct mipi_dsi_multi_context dsi_ctx;

[Severity: High]
Does leaving dsi_ctx uninitialized here leave dsi_ctx.accum_err with
random stack garbage?

The helper dsi_link_switch() only assigns the dsi pointer, so subsequent
multi-context calls like mipi_dsi_dcs_set_display_on_multi() might immediately
return if accum_err is non-zero, silently skipping the initialization.

> +
> +	dsi_link_switch(ctx, &dsi_ctx, 0);
> +	mipi_dsi_dcs_set_display_on_multi(&dsi_ctx);
> +	dsi_link_switch(ctx, &dsi_ctx, 1);
> +	mipi_dsi_dcs_set_display_on_multi(&dsi_ctx);
> +	mipi_dsi_msleep(&dsi_ctx, 150);
> +
> +	dsi_link_switch(ctx, &dsi_ctx, 0);
> +	mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
> +	dsi_link_switch(ctx, &dsi_ctx, 1);
> +	mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
> +	mipi_dsi_msleep(&dsi_ctx, 50);

[Severity: High]
Is it intentional to send the Set Display On command before Exit Sleep Mode?

According to the MIPI DCS specification, the display must exit sleep mode and
stabilize before it can process the Set Display On command. Sending these
commands in this order will likely result in the panel ignoring Set Display On,
causing it to remain blank.

> +
> +	return dsi_ctx.accum_err;
> +}
> +
> +static int renesas_r63419_disable(struct drm_panel *panel)
> +{
> +	struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
> +	struct mipi_dsi_multi_context dsi_ctx;

[Severity: High]
Like in renesas_r63419_on(), can this uninitialized struct leave
dsi_ctx.accum_err with stack garbage? This might cause the panel disable
commands to be silently skipped.

> +
> +	dsi_link_switch(ctx, &dsi_ctx, 0);
> +	mipi_dsi_dcs_set_display_off_multi(&dsi_ctx);

[ ... ]

> +static int renesas_r63419_probe(struct mipi_dsi_device *dsi)
> +{

[ ... ]

> +	ret = devm_drm_panel_add(dev, &ctx->panel);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to add panel\n");
> +
> +	/* Configure and attach both DSI devices */
> +	for (i = 0; i < ARRAY_SIZE(ctx->dsi); i++) {
> +		ctx->dsi[i]->lanes = ctx->desc->lanes;
> +		ctx->dsi[i]->format = ctx->desc->format;
> +		ctx->dsi[i]->mode_flags = ctx->desc->mode_flags;
> +
> +		ret = devm_mipi_dsi_attach(dev, ctx->dsi[i]);

[Severity: High]
Could registering the panel before the DSI hardware is attached cause a race
condition?

If a bridge driver concurrently finds the panel and triggers a display enable
sequence, it might invoke the panel's callbacks before the DSI endpoints are
actually attached, leading to DCS command timeouts or crashes.

Additionally, because devm actions are executed in reverse order on cleanup,
the DSI devices would be detached before the panel is unregistered, exposing
an unattached panel during driver unload. Should devm_drm_panel_add() be
called only after all hardware setup and DSI attachments are complete?

> +		if (ret < 0)
> +			return dev_err_probe(dev, ret,
> +					     "Failed to attach DSI device %d\n", i);
> +	}
> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260521-topic-sm8650-ayaneo-pocket-s2-r63419-v5-0-dd5700299390@linaro.org?part=2