On Sun, 24 Mar 2024 10:21:28 +0100
Christophe JAILLET <christophe.jaillet@xxxxxxxxxx> wrote:
> Le 23/03/2024 à 22:25, Marek Behún a écrit :
> > On Sat, 23 Mar 2024 22:10:40 +0100
> > Christophe JAILLET <christophe.jaillet@xxxxxxxxxx> wrote:
> >
>
> ...
>
> >>> static int pvt_ts_dbgfs_create(struct pvt_device *pvt, struct device *dev)
> >>> {
> >>> - pvt->dbgfs_dir = debugfs_create_dir(dev_name(dev), NULL);
> >>> + pvt->dbgfs_dir = devm_debugfs_create_dir(dev, dev_name(dev), NULL);
> >>> + if (IS_ERR(pvt->dbgfs_dir))
> >>> + return PTR_ERR(pvt->dbgfs_dir);
> >>
> >> Not sure if the test and error handling should be added here.
> >> *If I'm correct*, functions related to debugfs already handle this case
> >> and just do nothing. And failure in debugfs related code is not
> >> considered as something that need to be reported and abort a probe function.
> >>
> >> Maybe the same other (already existing) tests in this patch should be
> >> removed as well, in a separated patch.
> >
> > Functions related to debugfs maybe do, but devm_ resource management
> > functions may fail to allocate release structure, and those errors need
> > to be handled, AFAIK.
>
> I would say no.
> If this memory allocation fails, then debugfs_create_dir() will not be
> called, but that's not a really big deal if the driver itself can still
> run normally without it.
debugfs_create_dir() will always be called. Resource allocation is done
afterwards, and if it fails, then the created dir will be removed.
But now I don't know what to do, because yes, it seems that the debugfs
errors are being ignored at many places...
>
> Up to you to leave it as-is or remove what I think is a useless error
> handling.
> At least, maybe it could be said in the commit log, so that maintainers
> can comment on it, if they don't spot the error handling you introduce.
>
> CJ
>
> >
> > Marek
> >
>
