debugfs resources were never cleaned in case of failure to register driver.
Fixes: 4ef027d5a367 ("staging: pi433: add debugfs interface")
Reported-by Dan Carpenter <[email protected]>
Signed-off-by: Shahar Avidar <[email protected]>
---
drivers/staging/pi433/pi433_if.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index b01ee145ff3c..77e37a5bd1a2 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -1415,6 +1415,7 @@ static int __init pi433_init(void)
return 0;
unreg_class_and_remove_dbfs:
+ debugfs_remove(root_dir);
class_unregister(&pi433_class);
unreg_chrdev:
unregister_chrdev(MAJOR(pi433_devt), pi433_spi_driver.driver.name);
--
2.34.1
I suggest to use the summary phrase “Call debugfs_remove() in case of
driver registration failure in pi433_init()” instead.
> debugfs resources were never cleaned in case of failure to register driver.
How do you think about to use a change description like the following?
Debugfs resources were not released after a call of
the function “spi_register_driver” failed.
Thus fix the exception handling accordingly.
Regards,
Markus
On Fri, Apr 05, 2024 at 12:42:38PM +0200, Markus Elfring wrote:
> I suggest to use the summary phrase “Call debugfs_remove() in case of
> driver registration failure in pi433_init()” instead.
>
>
> > debugfs resources were never cleaned in case of failure to register driver.
>
> How do you think about to use a change description like the following?
>
> Debugfs resources were not released after a call of
> the function “spi_register_driver” failed.
> Thus fix the exception handling accordingly.
>
>
> Regards,
> Markus
>
Hi,
This is the semi-friendly patch-bot of Greg Kroah-Hartman.
Markus, you seem to have sent a nonsensical or otherwise pointless
review comment to a patch submission on a Linux kernel developer mailing
list. I strongly suggest that you not do this anymore. Please do not
bother developers who are actively working to produce patches and
features with comments that, in the end, are a waste of time.
Patch submitter, please ignore Markus's suggestion; you do not need to
follow it at all. The person/bot/AI that sent it is being ignored by
almost all Linux kernel maintainers for having a persistent pattern of
behavior of producing distracting and pointless commentary, and
inability to adapt to feedback. Please feel free to also ignore emails
from them.
thanks,
greg k-h's patch email bot