Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/bridge: tc358762: Error state leak in post_disable breaks next enable --
commit d2e59cf65b7853d5bbc77858afb718b43405bd7b Author: Tomi Valkeinen <[email protected]> drm/bridge: tc358762: Improve DPI enable handling This commit clears the DPIENABLE bit at the start of display enablement to avoid temporary wrong timings, and sets it later with the rest of the LCDCTRL configuration. It also explicitly disables DPIENABLE when disabling the bridge. > diff --git a/drivers/gpu/drm/bridge/tc358762.c > b/drivers/gpu/drm/bridge/tc358762.c > index 91bc79d36a744..19f328b6e7980 100644 > --- a/drivers/gpu/drm/bridge/tc358762.c > +++ b/drivers/gpu/drm/bridge/tc358762.c [ ... ] > @@ -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] Can this leak an error state that breaks the next enable cycle? If this newly added tc358762_write() fails during the post_disable phase (for example, due to a transient DSI timeout or host teardown state), it will set ctx->error to a negative error code. Unlike the initialization path which calls tc358762_clear_error(), tc358762_post_disable() does not clear ctx->error. When the display is later re-enabled, all subsequent hardware configuration writes in tc358762_init() will be silently skipped because tc358762_write() checks this cached error state: tc358762_write() { if (ctx->error) return; ... } Will this leave the hardware uninitialized and the display persistently broken until the module is reloaded? > if (ctx->reset_gpio) > gpiod_set_value_cansleep(ctx->reset_gpio, 0); > -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=6
