Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:

Pre-existing issues:
- [High] Sticky error state from post_disable infects subsequent enable 
sequence.
--

commit f76c8643501a53ed324e8fe4854b3ed95f3e36b5
Author: Tomi Valkeinen <[email protected]>

drm/bridge: tc358762: Move tc358762_init() into tc358762_enable()

The only thing tc358762_enable() does is call tc358762_init(). Inline
the tc358762_init() into tc358762_enable(), for simplicity and to make
it easier to improve the tc358762_enable() in the following commits. No
functional change.

> diff --git a/drivers/gpu/drm/bridge/tc358762.c 
> b/drivers/gpu/drm/bridge/tc358762.c
> index 3a2e6a97feb87..ff79134417522 100644
> --- a/drivers/gpu/drm/bridge/tc358762.c
> +++ b/drivers/gpu/drm/bridge/tc358762.c
> @@ -138,9 +138,56 @@ static inline struct tc358762 *bridge_to_tc358762(struct 
> drm_bridge *bridge)
[ ... ]
> +static void tc358762_post_disable(struct drm_bridge *bridge,
> +                               struct drm_atomic_commit *state)
> +{
[ ... ]
> +     ctx->pre_enabled = false;
> +
> +     /* Turn off the DPI output */
> +     tc358762_write(ctx, LCDCTRL, 0);

[Severity: High]
This isn't a bug introduced by this patch, but if this write fails, it sets
ctx->error which does not appear to be cleared at the end of
tc358762_post_disable(). Could this leak the error state?

> +
> +     if (ctx->reset_gpio)
> +             gpiod_set_value_cansleep(ctx->reset_gpio, 0);
[ ... ]
> +static void tc358762_enable(struct drm_bridge *bridge,
> +                         struct drm_atomic_commit *state)
> +{
> +     struct tc358762 *ctx = bridge_to_tc358762(bridge);
>       u32 lcdctrl;
> +     int ret;
>  
>       /*
>        * DPIENABLE has reset default of 1. Make sure we don't output on

[Severity: High]
This is a pre-existing issue, but does a leftover ctx->error from a prior
tc358762_post_disable() cause all subsequent initialization writes in
tc358762_enable() to be silently skipped?

If so, would this cause the display to permanently fail on subsequent enables,
such as after suspend and resume?

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=10

Reply via email to