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 > > >