linux-kernel - Re: [PATCH v2 34/35] drm/bridge: tc358768: Convert to atomic helpers

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <pbeqsf7buhgbrxybexhcxzdwitcb2ioa3as7itp2mxj2hybuji@sbh744trp3au>
Date: Wed, 12 Feb 2025 12:51:50 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
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>, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 34/35] drm/bridge: tc358768: Convert to atomic helpers

On Wed, Feb 12, 2025 at 09:24:21AM +0100, Maxime Ripard wrote:
> On Wed, Feb 12, 2025 at 02:38:52AM +0200, Dmitry Baryshkov wrote:
> > On Tue, Feb 11, 2025 at 03:33:58PM +0100, Maxime Ripard wrote:
> > > On Sun, Feb 09, 2025 at 09:13:36AM +0200, Dmitry Baryshkov wrote:
> > > > On Tue, Feb 04, 2025 at 03:58:02PM +0100, Maxime Ripard wrote:
> > > > > The tc358768 driver follows the drm_encoder->crtc pointer that is
> > > > > deprecated and shouldn't be used by atomic drivers.
> > > > > 
> > > > > This was due to the fact that we did't have any other alternative to
> > > > > retrieve the CRTC pointer. Fortunately, the crtc pointer is now provided
> > > > > in the bridge state, so we can move to atomic callbacks and drop that
> > > > > deprecated pointer usage.
> > > > > 
> > > > > Signed-off-by: Maxime Ripard <mripard@...nel.org>
> > > > > ---
> > > > >  drivers/gpu/drm/bridge/tc358768.c | 30 +++++++++++++++++++++++-------
> > > > >  1 file changed, 23 insertions(+), 7 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/bridge/tc358768.c b/drivers/gpu/drm/bridge/tc358768.c
> > > > > index 6db18d1e8824dd7d387211d6d1e668645cf88bbe..6ff6b29e8075d7c6fa0b74b4fec83c5230512d96 100644
> > > > > --- a/drivers/gpu/drm/bridge/tc358768.c
> > > > > +++ b/drivers/gpu/drm/bridge/tc358768.c
> > > > > @@ -601,17 +601,29 @@ static void tc358768_bridge_disable(struct drm_bridge *bridge)
> > > > >  	ret = tc358768_clear_error(priv);
> > > > >  	if (ret)
> > > > >  		dev_warn(priv->dev, "Software disable failed: %d\n", ret);
> > > > >  }
> > > > >  
> > > > > +static void tc358768_bridge_atomic_disable(struct drm_bridge *bridge,
> > > > > +					   struct drm_atomic_state *state)
> > > > > +{
> > > > > +	tc358768_bridge_disable(bridge);
> > > > > +}
> > > > > +
> > > > 
> > > > Please change corresponding functions into atomic_disable() and
> > > > atomic_post_disable(). Calling sites have access to the atomic state, so
> > > > there is no need to have yet another wrapper.
> > > 
> > > It's pretty hard to do (at least without the hardware), both
> > > tc358768_bridge_disable() and tc358768_bridge_post_disable() have
> > > multiple call sites in the driver, and passing a state enabling the
> > > bridge doesn't make sense for those.
> > 
> > I think it makes sense. The function knows that the bridge needs to be
> > disabled. The state is totally unused (or it can be used to get
> > connectors / CRTC / etc).
> 
> That's the thing though, if we were to pass the state, it would be a
> state where the bridge is enabled, like, it would have an active CRTC.
> In a disable path, you wouldn't have it.
> 
> Another idea would be to just drop the call to disable the bridge, the
> assumption is that we can't fail in atomic_enable, so no driver actually
> tries to mitigate a failure. I'm not sure why this one would need to.

SGTM too.

-- 
With best wishes
Dmitry