| Message ID | 20200209105525.GA1620170@kroah.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | nouveau: no need to check return value of debugfs_create functions | expand |
On Sun, 9 Feb 2020 at 22:56, Greg Kroah-Hartman <gregkh@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@redhat.com> > Cc: David Airlie <airlied@linux.ie> > Cc: Daniel Vetter <daniel@ffwll.ch> > Cc: dri-devel@lists.freedesktop.org > Cc: nouveau@lists.freedesktop.org > Signed-off-by: Greg Kroah-Hartman <gregkh@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@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,
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
On 2/13/20 2:39 PM, Greg Kroah-Hartman wrote: > 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. > Oops, I see now that you have already been very busy with this. :) Looking good... thanks,
On Thu, Feb 13, 2020 at 11:39 PM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > 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... Just to avoid duplication, Wambui (cc'ed) just started working on this. Expect a lot more void return values and a pile of deleted code rsn. -Daniel
On Fri, Feb 14, 2020 at 12:30:48AM +0100, Daniel Vetter wrote: > On Thu, Feb 13, 2020 at 11:39 PM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > > 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... > > Just to avoid duplication, Wambui (cc'ed) just started working on > this. Expect a lot more void return values and a pile of deleted code > rsn. Nice! It's not duplication if I haven't started on it :) greg k-h
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,
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@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/gpu/drm/nouveau/nouveau_debugfs.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-)