All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Maíra Canal" <mcanal@igalia.com>
Cc: "Stephen Rothwell" <sfr@canb.auug.org.au>,
	"André Almeida" <andrealmeid@igalia.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	"Melissa Wen" <mwen@igalia.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>
Subject: Re: [PATCH 2/2] drm/debugfs: add descriptions to struct parameters
Date: Wed, 11 Jan 2023 23:40:43 +0100	[thread overview]
Message-ID: <Y7866924YruF9OrY@phenom.ffwll.local> (raw)
In-Reply-To: <c7cbcb01-d0ce-47bd-1d9d-e687ef9e5315@igalia.com>

On Mon, Jan 09, 2023 at 08:28:20AM -0300, Maíra Canal wrote:
> On 1/6/23 17:19, Daniel Vetter wrote:
> > On Thu, Jan 05, 2023 at 04:30:39PM -0300, Maíra Canal wrote:
> > > The structs drm_debugfs_info and drm_debugfs_entry don't have
> > > descriptions for their parameters, which is causing the following warnings:
> > > 
> > > include/drm/drm_debugfs.h:93: warning: Function parameter or member
> > > 'name' not described in 'drm_debugfs_info'
> > > include/drm/drm_debugfs.h:93: warning: Function parameter or member
> > > 'show' not described in 'drm_debugfs_info'
> > > include/drm/drm_debugfs.h:93: warning: Function parameter or member
> > > 'driver_features' not described in 'drm_debugfs_info'
> > > include/drm/drm_debugfs.h:93: warning: Function parameter or member
> > > 'data' not described in 'drm_debugfs_info'
> > > include/drm/drm_debugfs.h:105: warning: Function parameter or member
> > > 'dev' not described in 'drm_debugfs_entry'
> > > include/drm/drm_debugfs.h:105: warning: Function parameter or member
> > > 'file' not described in 'drm_debugfs_entry'
> > > include/drm/drm_debugfs.h:105: warning: Function parameter or member
> > > 'list' not described in 'drm_debugfs_entry'
> > > 
> > > Therefore, fix the warnings by adding descriptions to all struct
> > > parameters.
> > > 
> > > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Signed-off-by: Maíra Canal <mcanal@igalia.com>
> > > ---
> > >   include/drm/drm_debugfs.h | 18 ++++++++++++++++++
> > >   1 file changed, 18 insertions(+)
> > > 
> > > diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
> > > index 53b7297260a5..7616f457ce70 100644
> > > --- a/include/drm/drm_debugfs.h
> > > +++ b/include/drm/drm_debugfs.h
> > > @@ -86,9 +86,22 @@ struct drm_info_node {
> > >    * core.
> > >    */
> > >   struct drm_debugfs_info {
> > > +	/** @name: File name */
> > >   	const char *name;
> > > +
> > > +	/**
> > > +	 * @show:
> > > +	 *
> > > +	 * Show callback. &seq_file->private will be set to the &struct
> > > +	 * drm_debugfs_entry corresponding to the instance of this info
> > > +	 * on a given &struct drm_device.
> > 
> > So this is a bit late, but why don't we pass that drm_debugfs_entry as an
> > explicit parameter? Or maybe just the struct drm_device, because that and
> > the void *data is really all there is to pass along. Would give us more
> > type-safety, which really is the main reason for having drm-specific
> > debugfs functions.
> 
> It seems like a better idea to pass the drm_debugfs_entry as an explicit
> parameter. I can work on it, but I guess it is a better idea to finish
> the conversion of all drm_debugfs_create_files() to drm_debugfs_add_files()
> and then perform the change in the show() signature.

So drm_debugfs_entry still feels like a bit too high level, do callers
really need that? They get the void * and I guess need the struct
drm_device *

This really starts to matter more when we also roll this out for
connector/crtc, then you can give them directly a pointer to that. And the
drm_debugfs_entry thing becomes an implementation detail entirely.

Or do I miss something?

Also yes we can do that later on, it shouldn't be too annyoing to roll
out.
-Daniel
> 
> Best Regards,
> - Maíra Canal
> 
> > 
> > Either way, on the series: Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > 
> > > +	 */
> > >   	int (*show)(struct seq_file*, void*);
> > > +
> > > +	/** @driver_features: Required driver features for this entry. */
> > >   	u32 driver_features;
> > > +
> > > +	/** @data: Driver-private data, should not be device-specific. */
> > >   	void *data;
> > >   };
> > > @@ -99,8 +112,13 @@ struct drm_debugfs_info {
> > >    * drm_debugfs_info on a &struct drm_device.
> > >    */
> > >   struct drm_debugfs_entry {
> > > +	/** @dev: &struct drm_device for this node. */
> > >   	struct drm_device *dev;
> > > +
> > > +	/** @file: Template for this node. */
> > >   	struct drm_debugfs_info file;
> > > +
> > > +	/** @list: Linked list of all device nodes. */
> > >   	struct list_head list;
> > >   };
> > > -- 
> > > 2.39.0
> > > 
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Maíra Canal" <mcanal@igalia.com>
Cc: "Stephen Rothwell" <sfr@canb.auug.org.au>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Melissa Wen" <mwen@igalia.com>,
	"André Almeida" <andrealmeid@igalia.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/debugfs: add descriptions to struct parameters
Date: Wed, 11 Jan 2023 23:40:43 +0100	[thread overview]
Message-ID: <Y7866924YruF9OrY@phenom.ffwll.local> (raw)
In-Reply-To: <c7cbcb01-d0ce-47bd-1d9d-e687ef9e5315@igalia.com>

On Mon, Jan 09, 2023 at 08:28:20AM -0300, Maíra Canal wrote:
> On 1/6/23 17:19, Daniel Vetter wrote:
> > On Thu, Jan 05, 2023 at 04:30:39PM -0300, Maíra Canal wrote:
> > > The structs drm_debugfs_info and drm_debugfs_entry don't have
> > > descriptions for their parameters, which is causing the following warnings:
> > > 
> > > include/drm/drm_debugfs.h:93: warning: Function parameter or member
> > > 'name' not described in 'drm_debugfs_info'
> > > include/drm/drm_debugfs.h:93: warning: Function parameter or member
> > > 'show' not described in 'drm_debugfs_info'
> > > include/drm/drm_debugfs.h:93: warning: Function parameter or member
> > > 'driver_features' not described in 'drm_debugfs_info'
> > > include/drm/drm_debugfs.h:93: warning: Function parameter or member
> > > 'data' not described in 'drm_debugfs_info'
> > > include/drm/drm_debugfs.h:105: warning: Function parameter or member
> > > 'dev' not described in 'drm_debugfs_entry'
> > > include/drm/drm_debugfs.h:105: warning: Function parameter or member
> > > 'file' not described in 'drm_debugfs_entry'
> > > include/drm/drm_debugfs.h:105: warning: Function parameter or member
> > > 'list' not described in 'drm_debugfs_entry'
> > > 
> > > Therefore, fix the warnings by adding descriptions to all struct
> > > parameters.
> > > 
> > > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Signed-off-by: Maíra Canal <mcanal@igalia.com>
> > > ---
> > >   include/drm/drm_debugfs.h | 18 ++++++++++++++++++
> > >   1 file changed, 18 insertions(+)
> > > 
> > > diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
> > > index 53b7297260a5..7616f457ce70 100644
> > > --- a/include/drm/drm_debugfs.h
> > > +++ b/include/drm/drm_debugfs.h
> > > @@ -86,9 +86,22 @@ struct drm_info_node {
> > >    * core.
> > >    */
> > >   struct drm_debugfs_info {
> > > +	/** @name: File name */
> > >   	const char *name;
> > > +
> > > +	/**
> > > +	 * @show:
> > > +	 *
> > > +	 * Show callback. &seq_file->private will be set to the &struct
> > > +	 * drm_debugfs_entry corresponding to the instance of this info
> > > +	 * on a given &struct drm_device.
> > 
> > So this is a bit late, but why don't we pass that drm_debugfs_entry as an
> > explicit parameter? Or maybe just the struct drm_device, because that and
> > the void *data is really all there is to pass along. Would give us more
> > type-safety, which really is the main reason for having drm-specific
> > debugfs functions.
> 
> It seems like a better idea to pass the drm_debugfs_entry as an explicit
> parameter. I can work on it, but I guess it is a better idea to finish
> the conversion of all drm_debugfs_create_files() to drm_debugfs_add_files()
> and then perform the change in the show() signature.

So drm_debugfs_entry still feels like a bit too high level, do callers
really need that? They get the void * and I guess need the struct
drm_device *

This really starts to matter more when we also roll this out for
connector/crtc, then you can give them directly a pointer to that. And the
drm_debugfs_entry thing becomes an implementation detail entirely.

Or do I miss something?

Also yes we can do that later on, it shouldn't be too annyoing to roll
out.
-Daniel
> 
> Best Regards,
> - Maíra Canal
> 
> > 
> > Either way, on the series: Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > 
> > > +	 */
> > >   	int (*show)(struct seq_file*, void*);
> > > +
> > > +	/** @driver_features: Required driver features for this entry. */
> > >   	u32 driver_features;
> > > +
> > > +	/** @data: Driver-private data, should not be device-specific. */
> > >   	void *data;
> > >   };
> > > @@ -99,8 +112,13 @@ struct drm_debugfs_info {
> > >    * drm_debugfs_info on a &struct drm_device.
> > >    */
> > >   struct drm_debugfs_entry {
> > > +	/** @dev: &struct drm_device for this node. */
> > >   	struct drm_device *dev;
> > > +
> > > +	/** @file: Template for this node. */
> > >   	struct drm_debugfs_info file;
> > > +
> > > +	/** @list: Linked list of all device nodes. */
> > >   	struct list_head list;
> > >   };
> > > -- 
> > > 2.39.0
> > > 
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2023-01-11 22:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05 19:30 [PATCH 1/2] drm/debugfs: use octal permissions instead of symbolic permissions Maíra Canal
2023-01-05 19:30 ` Maíra Canal
2023-01-05 19:30 ` [PATCH 2/2] drm/debugfs: add descriptions to struct parameters Maíra Canal
2023-01-05 19:30   ` Maíra Canal
2023-01-06 20:19   ` Daniel Vetter
2023-01-06 20:19     ` Daniel Vetter
2023-01-09 11:28     ` Maíra Canal
2023-01-11 22:40       ` Daniel Vetter [this message]
2023-01-11 22:40         ` Daniel Vetter
2023-01-10 14:06   ` Maíra Canal
2023-01-09  9:22 ` [PATCH 1/2] drm/debugfs: use octal permissions instead of symbolic permissions Jani Nikula
2023-01-09  9:22   ` Jani Nikula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y7866924YruF9OrY@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=andrealmeid@igalia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcanal@igalia.com \
    --cc=mwen@igalia.com \
    --cc=sfr@canb.auug.org.au \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.