Re: [PATCH v4 10/13] drm/bridge: tc358762: Move tc358762_init() into tc358762_enable()

[sashiko-bot@kernel.org]

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 <tomi.valkeinen@ideasonboard.com>

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/20260907-tc358762-fixes-v4-0-e3fc3ab5cd83@ideasonboard.com?part=10