Re: [PATCH 22/29] drm/bridge: Rename atomic hooks parameters to drop old prefix

[Simona Vetter <simona.vetter@ffwll.ch>]

On Fri, Jan 17, 2025 at 03:50:09PM +0100, Maxime Ripard wrote:
> On Thu, Jan 16, 2025 at 12:34:12PM +0100, Simona Vetter wrote:
> > On Wed, Jan 15, 2025 at 10:05:29PM +0100, Maxime Ripard wrote:
> > > All the bridge atomic hooks were using the old_bridge_state name for
> > > their drm_bridge_state parameter. However, this state is the current
> > > state being committed for all of them, which ends up being confusing.
> > > 
> > > Let's rename it to bridge_state for all of them.
> > > 
> > > Signed-off-by: Maxime Ripard <mripard@kernel.org>
> > > ---
> > >  include/drm/drm_bridge.h | 8 ++++----
> > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > > index 4b84faf14e368310dd20aa964e8178ec80aa6fa7..8e18130be8bb85fc2463917dde9bf1d281934184 100644
> > > --- a/include/drm/drm_bridge.h
> > > +++ b/include/drm/drm_bridge.h
> > > @@ -303,11 +303,11 @@ struct drm_bridge_funcs {
> > >  	 * there is one) when this callback is called.
> > >  	 *
> > >  	 * The @atomic_pre_enable callback is optional.
> > >  	 */
> > >  	void (*atomic_pre_enable)(struct drm_bridge *bridge,
> > > -				  struct drm_bridge_state *old_bridge_state);
> > > +				  struct drm_bridge_state *bridge_state);
> > >  
> > >  	/**
> > >  	 * @atomic_enable:
> > >  	 *
> > >  	 * This callback should enable the bridge. It is called right after
> > > @@ -323,11 +323,11 @@ struct drm_bridge_funcs {
> > >  	 * chain if there is one.
> > >  	 *
> > >  	 * The @atomic_enable callback is optional.
> > >  	 */
> > >  	void (*atomic_enable)(struct drm_bridge *bridge,
> > > -			      struct drm_bridge_state *old_bridge_state);
> > > +			      struct drm_bridge_state *bridge_state);
> > 
> > Checked this one, and it very clearly passes the old state.
> 
> Urgh, you're right
> 
> > Because the new state you can get by looking at bridge->state.
> 
> Bridge->state doesn't exist though.

Yeah it's defacto your helper to go find the private object, deref the
->state pointer in there and then cast to the right type. But that again
has a bit the locking issue since sometimes you must hold the modeset
lock, sometimes not.

If we instead always go through the drm_atomic_state lookup then we can
require the modeset lock in the other helper for the bridge ->
bridge_state lookup, and things become much harder for drivers to get
wrong.

> > So this looks very wrong.
> > 
> > If you want to fully update the pattern, pass the drm_atomic_state
> > instead, and let callbacks lookup any additional states they use as
> > needed.
> 
> Yeah, that's probably the best option. I think I still have the
> coccinelle scripts I used for the others somewhere.

Yeah cocci would help here.
-Sima
-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch