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: <20250226123208.272e7766@booty>
Date: Wed, 26 Feb 2025 12:32:08 +0100
From: Luca Ceresoli <luca.ceresoli@...tlin.com>
To: Jani Nikula <jani.nikula@...ux.intel.com>
Cc: 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>, Maarten
 Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
 <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David Airlie
 <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Dmitry Baryshkov
 <dmitry.baryshkov@...aro.org>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 1/2] drm/bridge: move bridges_show logic from
 drm_debugfs.c

Hello Jani,

On Tue, 25 Feb 2025 20:21:50 +0200
Jani Nikula <jani.nikula@...ux.intel.com> wrote:

> On Tue, 25 Feb 2025, Luca Ceresoli <luca.ceresoli@...tlin.com> wrote:
> > Hello Jani,
> >
> > On Tue, 25 Feb 2025 18:36:41 +0200
> > Jani Nikula <jani.nikula@...ux.intel.com> wrote:
> >  
> >> On Tue, 25 Feb 2025, Luca Ceresoli <luca.ceresoli@...tlin.com> wrote:  
> >> > In preparation to expose more info about bridges in debugfs, which will
> >> > require more insight into drm_bridge data structures, move the bridges_show
> >> > code to drm_bridge.c.
> >> >
> >> > Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> >> > Signed-off-by: Luca Ceresoli <luca.ceresoli@...tlin.com>    
> >> 
> >> I hate myself for doing this on a patch that's at v7... but here goes.  
> >
> > Please don't! :-) This patch is new in v7, and a different (and
> > definitely worse) approach was present in v6, but there was nothing
> > before.
> >  
> >> Perhaps consider moving the bridges debugfs creation and fops to
> >> drm_bridge.c instead of just adding
> >> drm_bridge_debugfs_show_encoder_bridges().
> >> 
> >> For example, add drm_bridge_debugfs_add(struct drm_encoder *encoder),
> >> which then contains the debugfs_create_file() call.  
> >
> > I think it should go in drm_encoder.c, not drm_bridge.c, right? Here we
> > are showing the bridges attached to an encoder, so the entry point is
> > each encoder.  
> 
> I'm still thinking drm_bridge.c, because it's about bridges and their
> details. The encoder shouldn't care about bridge implementation details.

Ah, I think I now get what you mean.

Current code is:

drm_encoder_register_all()                             [drm_encoder.c]
 -> drm_debugfs_encoder_add                            [drm_debugfs.c]
   -> debugfs_create_file("bridges"...  &bridges_fops) [drm_debugfs.c]
                                    [bridges_fops is in drm_debugfs.c]

Moving the last 2 lines to drm_bridge.c and into a new function we'd
have:

drm_encoder_register_all()                             [drm_encoder.c]
 -> drm_debugfs_encoder_add [*]                        [drm_debugfs.c]
  -> drm_bridge_debugfs_add_encoder_bridges_file (NEW) [drm_bridge.c]
   -> debugfs_create_file("bridges"...  &bridges_fops) [drm_bridge.c]
                                    [bridges_fops is in drm_bridge.c]

Potentially [*] could be moved to drm_encoder.c, but that is not bridge
related and can be done as a future step.

Is this what you had in mind?

> > On the other hand in patch 2 we should move the
> > drm_debugfs_global_add() code to drm_bridge.c, as it's showing bridges
> > ina encoder-independent way.  
> 
> Agreed on that.
> 
> > And finally drm_bridge should export the common
> > drm_bridge_debugfs_show_bridge() function to drm_encoder.c.  
> 
> Disagree. That will still require the EXPORT and #ifdefs around
> CONFIG_DEBUG_FS.

With the above-sketched idea I agree we wouldn't need to export
drm_bridge_debugfs_show_bridge().

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ