linux-kernel - Re: [PATCH v5 14/16] drm/bridge: tc358768: Stop disabling when failing to enable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z8nDyNVQ5p007Mw6@phenom.ffwll.local>
Date: Thu, 6 Mar 2025 16:48:24 +0100
From: Simona Vetter <simona.vetter@...ll.ch>
To: Maxime Ripard <mripard@...nel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Andrzej Hajda <andrzej.hajda@...el.com>,
	Neil Armstrong <neil.armstrong@...aro.org>,
	Robert Foss <rfoss@...nel.org>,
	Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
	Jonas Karlman <jonas@...boo.se>,
	Jernej Skrabec <jernej.skrabec@...il.com>,
	Douglas Anderson <dianders@...omium.org>,
	Herve Codina <herve.codina@...tlin.com>,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Subject: Re: [PATCH v5 14/16] drm/bridge: tc358768: Stop disabling when
 failing to enable

On Tue, Mar 04, 2025 at 12:10:57PM +0100, Maxime Ripard wrote:
> The tc358768 bridge driver, if enabling it fails, tries to disable it.
> This is pretty uncommon in bridge drivers, and also stands in the way
> for further reworks.
> 
> Worse, since pre_enable and enable aren't expected to fail, disable and
> post_disable might be called twice: once to handle the failure, and once
> to actually disable the bridge.
> 
> Since post_disable uses regulators and clocks, this would lead to enable
> count imbalances.
> 
> In order to prevent that imbalance, and to allow further reworks, let's
> drop the calls to disable and post_disable, but keep the warning to let
> users know about what's going on.
> 
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> Signed-off-by: Maxime Ripard <mripard@...nel.org>

Yeah proper way to clear these would be like any other link failure:
- Launch async worker to do a bridge reset with the fancy new helper.
- Set the link-status attribute if you can't automatically fix it and let
  userspace sort out the mess.

Maybe we need to improve the docs a bit more?
-Sima

> ---
>  drivers/gpu/drm/bridge/tc358768.c | 10 ++--------
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/tc358768.c b/drivers/gpu/drm/bridge/tc358768.c
> index 6db18d1e8824dd7d387211d6d1e668645cf88bbe..6b65ba8aed86012bc0f464bd5ee44325dae677c6 100644
> --- a/drivers/gpu/drm/bridge/tc358768.c
> +++ b/drivers/gpu/drm/bridge/tc358768.c
> @@ -1075,15 +1075,12 @@ static void tc358768_bridge_pre_enable(struct drm_bridge *bridge)
>  	val = TC358768_DSI_CONFW_MODE_CLR | TC358768_DSI_CONFW_ADDR_DSI_CONTROL;
>  	val |= TC358768_DSI_CONTROL_DIS_MODE; /* DSI mode */
>  	tc358768_write(priv, TC358768_DSI_CONFW, val);
>  
>  	ret = tc358768_clear_error(priv);
> -	if (ret) {
> +	if (ret)
>  		dev_err(dev, "Bridge pre_enable failed: %d\n", ret);
> -		tc358768_bridge_disable(bridge);
> -		tc358768_bridge_post_disable(bridge);
> -	}
>  }
>  
>  static void tc358768_bridge_enable(struct drm_bridge *bridge)
>  {
>  	struct tc358768_priv *priv = bridge_to_tc358768(bridge);
> @@ -1099,15 +1096,12 @@ static void tc358768_bridge_enable(struct drm_bridge *bridge)
>  
>  	/* set PP_en */
>  	tc358768_update_bits(priv, TC358768_CONFCTL, BIT(6), BIT(6));
>  
>  	ret = tc358768_clear_error(priv);
> -	if (ret) {
> +	if (ret)
>  		dev_err(priv->dev, "Bridge enable failed: %d\n", ret);
> -		tc358768_bridge_disable(bridge);
> -		tc358768_bridge_post_disable(bridge);
> -	}
>  }
>  
>  #define MAX_INPUT_SEL_FORMATS	1
>  
>  static u32 *
> 
> -- 
> 2.48.1
> 

-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch