On Mon, Apr 30, 2018 at 06:34:03AM -0700, Guenter Roeck wrote:
> On 04/30/2018 05:41 AM, Heikki Krogerus wrote:
> > Removing the "fusb302" debugfs directory when unloading
> > the driver. That allows the driver to be loaded more then
> > ones.
> >
> > This fixes an issue where the driver, if unloaded, can't be
> > re-loaded, as the "fusb302" debugfs directory already
> > exists. While here, removing useless condition when creating
> > the debugfs directory.
> >
> > Fixes: 76f0c53d08b9 ("usb: typec: fusb302: Move out of staging")
> > Signed-off-by: Heikki Krogerus <heikki.kroge...@linux.intel.com>
> > ---
> > drivers/usb/typec/fusb302/fusb302.c | 9 ++++-----
> > 1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/usb/typec/fusb302/fusb302.c
> > b/drivers/usb/typec/fusb302/fusb302.c
> > index eba6bb890b17..0e5d0aa052f5 100644
> > --- a/drivers/usb/typec/fusb302/fusb302.c
> > +++ b/drivers/usb/typec/fusb302/fusb302.c
> > @@ -218,11 +218,9 @@ static struct dentry *rootdir;
> > static int fusb302_debugfs_init(struct fusb302_chip *chip)
> > {
> > mutex_init(&chip->logbuffer_lock);
> > - if (!rootdir) {
> > - rootdir = debugfs_create_dir("fusb302", NULL);
> > - if (!rootdir)
> > - return -ENOMEM;
> > - }
>
> I think the idea here was to permit more than one instance of the driver,
> and have all debugfs file entries under the fusb302 directory. Loading the
> second instance will fail after this patch is applied.
OK, need to come up with something else for this issue then.
> > + rootdir = debugfs_create_dir("fusb302", NULL);
> > + if (!rootdir)
> > + return -ENOMEM;
> > chip->dentry = debugfs_create_file(dev_name(chip->dev),
> > S_IFREG | 0444, rootdir,
> > @@ -234,6 +232,7 @@ static int fusb302_debugfs_init(struct fusb302_chip
> > *chip)
> > static void fusb302_debugfs_exit(struct fusb302_chip *chip)
> > {
> > debugfs_remove(chip->dentry);
> > + debugfs_remove(rootdir); > }
> > #else
> >
Thanks,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
