linux-kernel - Re: [PATCH v3 32/37] drm/bridge: Make encoder pointer deprecated

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: <Z7Nl8JiFncngynNy@phenom.ffwll.local>
Date: Mon, 17 Feb 2025 17:38:08 +0100
From: Simona Vetter <simona.vetter@...ll.ch>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Maxime Ripard <mripard@...nel.org>,
	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 v3 32/37] drm/bridge: Make encoder pointer deprecated

On Fri, Feb 14, 2025 at 03:29:12PM +0200, Dmitry Baryshkov wrote:
> On Fri, Feb 14, 2025 at 02:07:18PM +0100, Maxime Ripard wrote:
> > On Thu, Feb 13, 2025 at 06:35:15PM +0200, Dmitry Baryshkov wrote:
> > > On Thu, Feb 13, 2025 at 03:43:51PM +0100, Maxime Ripard wrote:
> > > > Other entities (drm_connector.crtc, drm_encoder.crtc, etc.) have
> > > > pointer to other currently bound entities. They are all considered
> > > > relevant only for non-atomic drivers, and generally perceived as
> > > > deprecated in favour of the equivalent pointers in the atomic states.
> > > 
> > > I think there is a significant difference between mentioned fields and
> > > drm_bridge.encoder: the former fields are variable and can change. The
> > > latter one is static and set at the bridge attachment time. Nevertheless
> > > I think it is a good idea to deprecate it.
> > 
> > I'm sorry, it's not clear to me here what you want here either. Do you
> > want me to change anything to that patch?
> 
> Well... I was thinking if we should expand the commit message. Most
> likely it's fine though. In the end, I've r-b'ed the patch.

I think this one is wrong, since the bridge->encoder link is static. This
is unlike the connector->encoder->crtc chain, which isn't, and where you
really want to go through the atomic states or you get funny stuff.

I don't think we have bridge chains with multiple connectors though, so
this is fairly academic and so maybe still a good idea to make this all
more flexible? Unless I've missed the memo and atomic bridges have
flexible routing, and in that case yes this shouldn't be used.

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