[PATCH] malidp: no need to check return value of debugfs_create functions

Liviu Dudau liviu.dudau at arm.com
Fri Jun 14 09:07:19 UTC 2019


On Thu, Jun 13, 2019 at 07:42:15PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jun 13, 2019 at 05:27:55PM +0100, Liviu Dudau wrote:
> > On Thu, Jun 13, 2019 at 05:57:13PM +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Jun 13, 2019 at 03:52:22PM +0100, Liviu Dudau wrote:
> > > > On Thu, Jun 13, 2019 at 03:28:29PM +0200, 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.
> > > > 
> > > > I remember when writing this code and testing not fully complete code that left
> > > > nodes around on removing the module that there were errors being returned by
> > > > debugfs_create_file(). Has that changed since 2 years ago? :)
> > > 
> > > Errors can be returned if you do something foolish:
> > > 	- pass an error as a parent pointer
> > > 	- pass a name that is already present
> > 
> > That is what I was hitting previously. If we follow the new advice of not
> > checking for errors does this mean I can now start to hide debugfs entries
> > by touching some debugfs files before modules get loaded?
> 
> How can you "touch" a debugfs file today?

Touché! Yes, last time it was through my sloppy coding :)

> 
> And even if there is a duplicate debugfs file, you shouldn't care as
> your driver should keep going even if creation of it fails as no
> functionality of the code should ever rely on debugfs.

Agree and understood. Thanks for taking the time to explain it to me!

Best regards,
Liviu

> 
> thanks,
> 
> greg k-h

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯


More information about the dri-devel mailing list