Nouveau - Feb 2020 - [PATCH] nouveau: no need to check return value of debugfs_create functions

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Ben Skeggs <bskeggs at redhat.com>
Cc: David Airlie <airlied at linux.ie>
Cc: Daniel Vetter <daniel at ffwll.ch>
Cc: dri-devel at lists.freedesktop.org
Cc: nouveau at lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 080e964d49aa..d1c82fc45a68 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -224,14 +224,10 @@ nouveau_drm_debugfs_init(struct drm_minor *minor)
 	struct dentry *dentry;
 	int i;
 
-	for (i = 0; i < ARRAY_SIZE(nouveau_debugfs_files); i++) {
-		dentry = debugfs_create_file(nouveau_debugfs_files[i].name,
-					     S_IRUGO | S_IWUSR,
-					     minor->debugfs_root, minor->dev,
-					     nouveau_debugfs_files[i].fops);
-		if (!dentry)
-			return -ENOMEM;
-	}
+	for (i = 0; i < ARRAY_SIZE(nouveau_debugfs_files); i++)
+		debugfs_create_file(nouveau_debugfs_files[i].name,
+				    S_IRUGO | S_IWUSR, minor->debugfs_root,
+				    minor->dev, nouveau_debugfs_files[i].fops);
 
 	drm_debugfs_create_files(nouveau_debugfs_list,
 				 NOUVEAU_DEBUGFS_ENTRIES,
-- 
2.25.0

On Sun, 9 Feb 2020 at 22:56, Greg Kroah-Hartman
<gregkh at linuxfoundation.org> wrote:
>
> When calling debugfs functions, there is no need to ever check the
> return value.  The function can work or not, but the code logic should
> never do something different based on this.
Thanks!
>
> Cc: Ben Skeggs <bskeggs at redhat.com>
> Cc: David Airlie <airlied at linux.ie>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: dri-devel at lists.freedesktop.org
> Cc: nouveau at lists.freedesktop.org
> Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> ---
>  drivers/gpu/drm/nouveau/nouveau_debugfs.c | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
> index 080e964d49aa..d1c82fc45a68 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
> @@ -224,14 +224,10 @@ nouveau_drm_debugfs_init(struct drm_minor *minor)
>         struct dentry *dentry;
>         int i;
>
> -       for (i = 0; i < ARRAY_SIZE(nouveau_debugfs_files); i++) {
> -               dentry = debugfs_create_file(nouveau_debugfs_files[i].name,
> -                                            S_IRUGO | S_IWUSR,
> -                                            minor->debugfs_root,
minor->dev,
> -                                           
nouveau_debugfs_files[i].fops);
> -               if (!dentry)
> -                       return -ENOMEM;
> -       }
> +       for (i = 0; i < ARRAY_SIZE(nouveau_debugfs_files); i++)
> +               debugfs_create_file(nouveau_debugfs_files[i].name,
> +                                   S_IRUGO | S_IWUSR,
minor->debugfs_root,
> +                                   minor->dev,
nouveau_debugfs_files[i].fops);
>
>         drm_debugfs_create_files(nouveau_debugfs_list,
>                                  NOUVEAU_DEBUGFS_ENTRIES,
> --
> 2.25.0
>
> _______________________________________________
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

On 2/9/20 2:55 AM, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value.  The function can work or not, but the code logic should
> never do something different based on this.
> 
Should we follow that line of reasoning further, and simply return void
from the debugfs functions--rather than playing whack-a-mole with this
indefinitely?


thanks,
-- 
John Hubbard
NVIDIA
> Cc: Ben Skeggs <bskeggs at redhat.com>
> Cc: David Airlie <airlied at linux.ie>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: dri-devel at lists.freedesktop.org
> Cc: nouveau at lists.freedesktop.org
> Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> ---
>  drivers/gpu/drm/nouveau/nouveau_debugfs.c | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
> index 080e964d49aa..d1c82fc45a68 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
> @@ -224,14 +224,10 @@ nouveau_drm_debugfs_init(struct drm_minor *minor)
>  	struct dentry *dentry;
>  	int i;
>  
> -	for (i = 0; i < ARRAY_SIZE(nouveau_debugfs_files); i++) {
> -		dentry = debugfs_create_file(nouveau_debugfs_files[i].name,
> -					     S_IRUGO | S_IWUSR,
> -					     minor->debugfs_root, minor->dev,
> -					     nouveau_debugfs_files[i].fops);
> -		if (!dentry)
> -			return -ENOMEM;
> -	}
> +	for (i = 0; i < ARRAY_SIZE(nouveau_debugfs_files); i++)
> +		debugfs_create_file(nouveau_debugfs_files[i].name,
> +				    S_IRUGO | S_IWUSR, minor->debugfs_root,
> +				    minor->dev, nouveau_debugfs_files[i].fops);
>  
>  	drm_debugfs_create_files(nouveau_debugfs_list,
>  				 NOUVEAU_DEBUGFS_ENTRIES,
>

On Thu, Feb 13, 2020 at 02:30:09PM -0800, John Hubbard
wrote:
> On 2/9/20 2:55 AM, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value.  The function can work or not, but the code logic should
> > never do something different based on this.
> > 
> 
> Should we follow that line of reasoning further, and simply return void
> from the debugfs functions--rather than playing whack-a-mole with this
> indefinitely?
That is what we (well I) have been doing.  Look at all of the changes
that have happened to include/linux/debugfs.h over the past few
releases.  I'm slowly winnowing down the api to make it impossible to
get wrong for this type of thing, and am almost there.

DRM is the big fish left to tackle, I have submitted some patches in the
past, but lots more cleanup needs to be done to get them into mergable
shape.  I just need to find the time...

thanks,

greg k-h