2022-03-31 07:14:26

by Fabio M. De Francesco

[permalink] [raw]
Subject: [PATCH v2] staging: unisys: Remove "struct dentry *eth_debugfs_dir"

There is no need for "struct dentry *eth_debugfs_dir" which is used for
debug / sysfs directories. Therefore, remove this "struct dentry" and
everything related (i.e., creation and removal).

As a side effect of this change, the code has no more need of the
"cleanup_register_netdev" label, which can also be removed.

Suggested-by: Dan Carpenter <[email protected]>
Suggested-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Fabio M. De Francesco <[email protected]>
---

v1 - v2: Add a couple of "Suggested-by" tags which were forgotten.
Thanks to Dan Carpenter and Greg Kroah-Hartman.

drivers/staging/unisys/visornic/visornic_main.c | 17 -----------------
1 file changed, 17 deletions(-)

diff --git a/drivers/staging/unisys/visornic/visornic_main.c b/drivers/staging/unisys/visornic/visornic_main.c
index 643432458105..bb7ec492503e 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -103,7 +103,6 @@ struct chanstat {
* @server_down: IOPART is down.
* @server_change_state: Processing SERVER_CHANGESTATE msg.
* @going_away: device is being torn down.
- * @struct *eth_debugfs_dir:
* @interrupts_rcvd:
* @interrupts_notme:
* @interrupts_disabled:
@@ -157,7 +156,6 @@ struct visornic_devdata {
bool server_down;
bool server_change_state;
bool going_away;
- struct dentry *eth_debugfs_dir;
u64 interrupts_rcvd;
u64 interrupts_notme;
u64 interrupts_disabled;
@@ -1919,24 +1917,10 @@ static int visornic_probe(struct visor_device *dev)
goto cleanup_napi_add;
}

- /* create debug/sysfs directories */
- devdata->eth_debugfs_dir = debugfs_create_dir(netdev->name,
- visornic_debugfs_dir);
- if (!devdata->eth_debugfs_dir) {
- dev_err(&dev->device,
- "%s debugfs_create_dir %s failed\n",
- __func__, netdev->name);
- err = -ENOMEM;
- goto cleanup_register_netdev;
- }
-
dev_info(&dev->device, "%s success netdev=%s\n",
__func__, netdev->name);
return 0;

-cleanup_register_netdev:
- unregister_netdev(netdev);
-
cleanup_napi_add:
visorbus_disable_channel_interrupts(dev);
netif_napi_del(&devdata->napi);
@@ -2002,7 +1986,6 @@ static void visornic_remove(struct visor_device *dev)
/* going_away prevents new items being added to the workqueues */
cancel_work_sync(&devdata->timeout_reset);

- debugfs_remove_recursive(devdata->eth_debugfs_dir);
/* this will call visornic_close() */
unregister_netdev(netdev);

--
2.34.1


2022-03-31 08:26:46

by Fabio M. De Francesco

[permalink] [raw]
Subject: Re: [PATCH v2] staging: unisys: Remove "struct dentry *eth_debugfs_dir"

On gioved? 31 marzo 2022 08:47:51 CEST Fabio M. De Francesco wrote:
> There is no need for "struct dentry *eth_debugfs_dir" which is used for
> debug / sysfs directories. Therefore, remove this "struct dentry" and
> everything related (i.e., creation and removal).
>
> As a side effect of this change, the code has no more need of the
> "cleanup_register_netdev" label, which can also be removed.
>
> Suggested-by: Dan Carpenter <[email protected]>
> Suggested-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Fabio M. De Francesco <[email protected]>
> ---
>
> v1 - v2: Add a couple of "Suggested-by" tags which were forgotten.
> Thanks to Dan Carpenter and Greg Kroah-Hartman.
>
> drivers/staging/unisys/visornic/visornic_main.c | 17 -----------------
> 1 file changed, 17 deletions(-)

As said some days ago, the email address of David Kershner at unisys.com
is not anymore reachable. Each time I submit patches for this Unisys'
driver I get the following message:

Delivery has failed to these recipients or groups:

David Kershner (david.kershner at unisys.com)
The email address you entered couldn't be found.
Please check the recipient's email address and try to resend the message.

Is it the case to remove his entry from the MAINTAINERS file? I'm asking
because I don't yet know how these kinds of issues are handled.

Any suggestions?

Thanks,

Fabio M. De Francesco



2022-03-31 09:06:21

by Dan Carpenter

[permalink] [raw]
Subject: Re: [PATCH v2] staging: unisys: Remove "struct dentry *eth_debugfs_dir"

On Thu, Mar 31, 2022 at 08:47:51AM +0200, Fabio M. De Francesco wrote:
> There is no need for "struct dentry *eth_debugfs_dir" which is used for
> debug / sysfs directories. Therefore, remove this "struct dentry" and
> everything related (i.e., creation and removal).
>
> As a side effect of this change, the code has no more need of the
> "cleanup_register_netdev" label, which can also be removed.
>
> Suggested-by: Dan Carpenter <[email protected]>
> Suggested-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Fabio M. De Francesco <[email protected]>
> ---
>
> v1 - v2: Add a couple of "Suggested-by" tags which were forgotten.
> Thanks to Dan Carpenter and Greg Kroah-Hartman.
>

Thanks!

Reviewed-by: Dan Carpenter <[email protected]>

regards,
dan carpenter


2022-03-31 11:12:13

by Dan Carpenter

[permalink] [raw]
Subject: Re: [PATCH v2] staging: unisys: Remove "struct dentry *eth_debugfs_dir"

On Thu, Mar 31, 2022 at 09:00:59AM +0200, Fabio M. De Francesco wrote:
> Is it the case to remove his entry from the MAINTAINERS file? I'm asking
> because I don't yet know how these kinds of issues are handled.

Yeah. Send a patch to remove David's address.

regards,
dan carpenter

2022-04-01 14:55:07

by Fabio M. De Francesco

[permalink] [raw]
Subject: Re: [PATCH v2] staging: unisys: Remove "struct dentry *eth_debugfs_dir"

On gioved? 31 marzo 2022 10:22:02 CEST Dan Carpenter wrote:
> On Thu, Mar 31, 2022 at 08:47:51AM +0200, Fabio M. De Francesco wrote:
> > There is no need for "struct dentry *eth_debugfs_dir" which is used for
> > debug / sysfs directories. Therefore, remove this "struct dentry" and
> > everything related (i.e., creation and removal).
> >
> > As a side effect of this change, the code has no more need of the
> > "cleanup_register_netdev" label, which can also be removed.
> >
> > Suggested-by: Dan Carpenter <[email protected]>
> > Suggested-by: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Fabio M. De Francesco <[email protected]>
> > ---
> >
> > v1 - v2: Add a couple of "Suggested-by" tags which were forgotten.
> > Thanks to Dan Carpenter and Greg Kroah-Hartman.
> >
>
> Thanks!
>
> Reviewed-by: Dan Carpenter <[email protected]>
>
> regards,
> dan carpenter
>
I've just noticed that visornic and visorhba do other calls to
debugfs_create_dir() and debugfs_create_file() functions.

I'm not sure whether or not this driver still needs those other calls.

Do you think that they should be removed as well as it has been done
in the patch above?

Thanks,

Fabio M. De Francesco



2022-04-01 15:27:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v2] staging: unisys: Remove "struct dentry *eth_debugfs_dir"

On Thu, Mar 31, 2022 at 06:58:58PM +0200, Fabio M. De Francesco wrote:
> On gioved? 31 marzo 2022 10:22:02 CEST Dan Carpenter wrote:
> > On Thu, Mar 31, 2022 at 08:47:51AM +0200, Fabio M. De Francesco wrote:
> > > There is no need for "struct dentry *eth_debugfs_dir" which is used for
> > > debug / sysfs directories. Therefore, remove this "struct dentry" and
> > > everything related (i.e., creation and removal).
> > >
> > > As a side effect of this change, the code has no more need of the
> > > "cleanup_register_netdev" label, which can also be removed.
> > >
> > > Suggested-by: Dan Carpenter <[email protected]>
> > > Suggested-by: Greg Kroah-Hartman <[email protected]>
> > > Signed-off-by: Fabio M. De Francesco <[email protected]>
> > > ---
> > >
> > > v1 - v2: Add a couple of "Suggested-by" tags which were forgotten.
> > > Thanks to Dan Carpenter and Greg Kroah-Hartman.
> > >
> >
> > Thanks!
> >
> > Reviewed-by: Dan Carpenter <[email protected]>
> >
> > regards,
> > dan carpenter
> >
> I've just noticed that visornic and visorhba do other calls to
> debugfs_create_dir() and debugfs_create_file() functions.
>
> I'm not sure whether or not this driver still needs those other calls.

It looks like those drivers create actual files in debugfs with
information in them, so I would leave them alone.

thanks,

greg k-h