From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 05C6ED3B7F2 for ; Mon, 8 Dec 2025 15:43:19 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6553210E050; Mon, 8 Dec 2025 15:43:18 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="DB6tzQVo"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6D56A10E050; Mon, 8 Dec 2025 15:43:17 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 2DEA240706; Mon, 8 Dec 2025 15:43:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ABD6CC4CEF1; Mon, 8 Dec 2025 15:43:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765208597; bh=nSKyTwyc6gtVXjKiksXBSB5Lqzmb0N8xQmXUhdtjILg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DB6tzQVow1mIGcQAHjPHTv7SmbtoopZ55mw6gMkW8RGl9CzJzV12z6RbWUuaOIMCR U4irgZsk84vlIwUMLvdTnFqF7Tpwsve5l+dFFDsbbQNlTC/o43D9nc9Qr2f3zD4255 jldBWat2Y1yHgNIgz6qWMCWKLrLCIM0zuKUByNOrN1StoDlknvKgEaNiNhFRcMF3ov U5yKafhRY1WmXRVccNCWjynyrlrckoXK0pmA6G46Hx3/OeNJ3K/fzOXFXUcOPuT7rM lHvim/AdiKuoTetGnWlgwY90cbK8GsvS0Dk1s+56cTZjb+qW7INbr1GfCJsihIs1+9 bpLjeab/8ezDQ== Date: Mon, 8 Dec 2025 16:43:14 +0100 From: Maxime Ripard To: Luca Ceresoli Cc: Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, Dmitry Baryshkov , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , dri-devel Subject: Re: [PATCH v2 05/16] drm/bridge: Switch private_obj initialization to atomic_create_state Message-ID: <20251208-impossible-successful-ibex-5bceac@houat> References: <20251014-drm-private-obj-reset-v2-0-6dd60e985e9d@kernel.org> <20251014-drm-private-obj-reset-v2-5-6dd60e985e9d@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="np463kq723pzn3cv" Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --np463kq723pzn3cv Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v2 05/16] drm/bridge: Switch private_obj initialization to atomic_create_state MIME-Version: 1.0 On Tue, Oct 21, 2025 at 10:17:13AM +0200, Luca Ceresoli wrote: > Hello Maxime, >=20 > On Tue Oct 14, 2025 at 11:31 AM CEST, Maxime Ripard wrote: > > The bridge implementation relies on a drm_private_obj, that is > > initialized by allocating and initializing a state, and then passing it > > to drm_private_obj_init. > > > > Since we're gradually moving away from that pattern to the more > > established one relying on a atomic_create_state implementation, let's > > migrate this instance to the new pattern. > > > > Reviewed-by: Dmitry Baryshkov > > Signed-off-by: Maxime Ripard > > --- > > > > Cc: Andrzej Hajda > > Cc: Neil Armstrong > > Cc: Robert Foss > > Cc: Laurent Pinchart > > Cc: Jonas Karlman > > Cc: Jernej Skrabec > > --- > > drivers/gpu/drm/drm_bridge.c | 33 ++++++++++++++++++--------------- > > 1 file changed, 18 insertions(+), 15 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > > index 630b5e6594e0affad9ba48791207c7b403da5db8..f0db891863428ee65625a6a= 3ed38f63ec802595e 100644 > > --- a/drivers/gpu/drm/drm_bridge.c > > +++ b/drivers/gpu/drm/drm_bridge.c > > @@ -394,11 +394,27 @@ drm_bridge_atomic_destroy_priv_state(struct drm_p= rivate_obj *obj, > > struct drm_bridge *bridge =3D drm_priv_to_bridge(obj); > > > > bridge->funcs->atomic_destroy_state(bridge, state); > > } > > > > +static struct drm_private_state * > > +drm_bridge_atomic_create_priv_state(struct drm_private_obj *obj) > > +{ > > + struct drm_bridge *bridge =3D drm_priv_to_bridge(obj); > > + struct drm_bridge_state *state; > > + > > + state =3D bridge->funcs->atomic_reset(bridge); > > + if (IS_ERR(state)) > > + return ERR_PTR(-ENOMEM); >=20 > This is slightly changing the behaviour, assuming that every error is > -ENOMEM, while in the current implementation any error code is just > propagated. I searched all .atomic_reset callbacks and apparently none can > return any other error, so this would not introduce a bug with current > drivers. However the atomic_reset docs say any ERR_PTR can be returned, > thus a future driver would be allowed to return another error value, even > thoug it's unlikely. The drm_bridge.c core having no control over what > other drivers do, I wonder whether we should just return ERR_PTR(state) > here, and keep the check on the drm_atomic_private_obj_init() return value > below. >=20 > I have no strong position about which direction is best however. Maybe > changing the docs to say "Return: only -ENOMEM", and add here a > WARN_ON(IS_ERR(state) && ERR_PTR(state) !=3D -ENOMEM)? No, it's a good catch, we should totally return state and not ignore it. Thanks! Maxime --np463kq723pzn3cv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCaTbyEQAKCRAnX84Zoj2+ dteFAX9ZL4Pq31U2P9HBQ8ChuZhD5ZSRdu8XOp09Jazz52V9CRwv5rkVFs6Mn8ON fxkfPwQBfjMU7bwOcFqy9TxCTRgpDtRB+NtwrLZxND5+Pn49YnGbZFJuEO5rOTi4 O/61/BAfGA== =93j9 -----END PGP SIGNATURE----- --np463kq723pzn3cv--