Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Unhandled error in tc358762_post_disable() poisons the accumulated error state, silently breaking subsequent bridge initialization. --
commit 28214859a6b5c3e5c579f3076ec1cf46dc47e5c5 Author: Tomi Valkeinen <[email protected]> drm/bridge: tc358762: Improve DPI enable handling This commit clears the DPIENABLE bit early during the display enable sequence to avoid a temporary DPI output with incorrect timings. It also disables the DPI output during the bridge disable phase. > diff --git a/drivers/gpu/drm/bridge/tc358762.c > b/drivers/gpu/drm/bridge/tc358762.c > index ee72978cd8d80..7654d4039a9d7 100644 > --- a/drivers/gpu/drm/bridge/tc358762.c > +++ b/drivers/gpu/drm/bridge/tc358762.c > @@ -134,6 +134,12 @@ static int tc358762_init(struct tc358762 *ctx) > { > u32 lcdctrl; > > + /* > + * DPIENABLE has reset default of 1. Make sure we don't output on > + * DPI until we have finished the coniguration. > + */ > + tc358762_write(ctx, LCDCTRL, 0); [Severity: High] If ctx->error is already set from a previous failure, will this write and all subsequent configuration writes in tc358762_init() be silently skipped? [ ... ] > @@ -185,6 +191,9 @@ static void tc358762_post_disable(struct drm_bridge > *bridge, > > ctx->pre_enabled = false; > > + /* Turn off the DPI output */ > + tc358762_write(ctx, LCDCTRL, 0); [Severity: High] Does this write need a corresponding tc358762_clear_error() call to clean up the accumulated error state? If this DSI write fails during tc358762_post_disable() (e.g., during a DPMS off cycle or modeset), ctx->error is set. Since it is not cleared in the teardown path, the error state persists into the next DPMS on cycle. When the display is later enabled via tc358762_init() or tc358762_enable(), the lingering ctx->error would cause every tc358762_write() to return immediately without touching the hardware. Could this transient failure prevent the hardware from being correctly configured during the next DPMS on cycle? > + > if (ctx->reset_gpio) > gpiod_set_value_cansleep(ctx->reset_gpio, 0); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=6
