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