Re: [PATCH v3 08/21] drm/panel: himax-hx8394: set prepare_prev_first

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incorrectly setting `prepare_prev_first = true` reverses the power-on sequence, causing the DSI host to drive the PHY (LP-11) before the panel is powered on, risking hardware latch-up.
--

--- Patch [8]: [PATCH v3 08/21] drm/panel: himax-hx8394: set prepare_prev_first ---
commit c09b3f2141b3b76647c1bce815022a8389dcf60f
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>

drm/panel: himax-hx8394: set prepare_prev_first

This commit sets the prepare_prev_first flag for the Himax hx8394 panel.
The flag reverses the pre_enable and prepare ordering in the DRM bridge
chain so the DSI host powers on before the panel.

> Sending DSI commands from the prepare() callback requires DSI link to be
> up at that point.

Is this description accurate? Looking at panel-himax-hx8394.c, the DSI
commands are actually sent in the enable callback, not prepare():

drivers/gpu/drm/panel/panel-himax-hx8394.c:hx8394_enable() {
    ...
    ctx->desc->init_sequence(&dsi_ctx);
    ...
}

During enable, the DSI host is already fully powered on and initialized,
rendering prepare_prev_first unnecessary.

> diff --git a/drivers/gpu/drm/panel/panel-himax-hx8394.c b/drivers/gpu/drm/panel/panel-himax-hx8394.c
> index c4d3e09a228da..d64f3521eb15b 100644
> --- a/drivers/gpu/drm/panel/panel-himax-hx8394.c
> +++ b/drivers/gpu/drm/panel/panel-himax-hx8394.c
> @@ -792,6 +792,8 @@ static int hx8394_probe(struct mipi_dsi_device *dsi)
>  	if (ret)
>  		return ret;
>  
> +	ctx->panel.prepare_prev_first = true;
> +

[Severity: High]
Does setting this flag reverse the power-on sequence, causing the DSI host
to drive the PHY (LP-11) before the panel is powered on?

Because of this flag, panel power-on executes after the host has already
driven the DSI lanes. For example, in hx8394_prepare():

drivers/gpu/drm/panel/panel-himax-hx8394.c:hx8394_prepare() {
    ...
    ret = regulator_enable(ctx->vcc);
    ...
}

This executes after the host is initialized, which is a hardware sequencing
violation. Could this lead to current leakage, potential hardware latch-up,
or PHY initialization timeouts on strict DSI hosts?

>  	drm_panel_add(&ctx->panel);
>  
>  	ret = mipi_dsi_attach(dsi);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260413-waveshare-dsi-touch-v3-0-3aeb53022c32@oss.qualcomm.com?part=8