linux-kernel - Re: [PATCH v3 30/37] drm/bridge: Assume that a bridge is atomic if it has atomic

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: <x2qp4dy7gsqns2czx5bml5ofdyfwsl7jhdmy5ptwslvoz3d56z@e7otlhrvmf5f>
Date: Fri, 14 Feb 2025 15:26:11 +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 v3 30/37] drm/bridge: Assume that a bridge is atomic if
 it has atomic_reset

On Fri, Feb 14, 2025 at 01:59:01PM +0100, Maxime Ripard wrote:
> On Thu, Feb 13, 2025 at 06:29:46PM +0200, Dmitry Baryshkov wrote:
> > On Thu, Feb 13, 2025 at 03:43:49PM +0100, Maxime Ripard wrote:
> > > The drm_atomic_bridge_check() runs the atomic_check callback if needed,
> > > or falls back to mode_fixup if it's not there.
> > > 
> > > Going forward, we'll need to setup the bridge atomic state even though
> > > drivers might not be implementing atomic_check at all.
> > > 
> > > We can thus switch to using drm_bridge_is_atomic() to take the atomic
> > > path, and do additional things there in the future, or go the mode_fixup
> > > route.
> > 
> > This will break bridges like tc358768, rcar_lvds and mtk_hdmi: they
> > implement atomic_reset() and mode_fixup().
> 
> What is your suggestion then? I kind of did what you were suggesting on
> patch 1, but it wasn't working. Then you want me to roll back to that,
> or something else?

Well, we just need to call mode_fixup. So something like:

	if (drm_bridge_is_atomic(bridge)) {
		bridge_state = drm_atomic_get_new_bridge_state(crtc_state->state,
							       bridge);
		if (WARN_ON(!bridge_state))
			return -EINVAL;
	}

	if (bridge->funcs->atomic_check) {
		/* drm_bridge_add() returns void, so there is no way to
		 * reject non-atomic bridges with atomic_check()
		 * callback.
		 */
		if (!bridge_state)
			return -EINVAL;
		ret = bridge->funcs->atomic_check(bridge, bridge_state,
						  crtc_state, conn_state);
		if (ret)
			return ret;
	} else if (bridge->funcs->mode_fixup) {
		if (!bridge->funcs->mode_fixup(bridge, &crtc_state->mode,
					       &crtc_state->adjusted_mode))
			return -EINVAL;
	}



-- 
With best wishes
Dmitry