Re: [PATCH v4 06/13] drm/bridge: tc358762: Improve DPI enable handling

[sashiko-bot@kernel.org]

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

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