linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Linyu Yuan <quic_linyyuan@quicinc.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH v3 4/6] usb: gadget: f_fs: add a device reference of usb_gadget->dev
Date: Wed, 29 Mar 2023 10:21:07 +0200	[thread overview]
Message-ID: <ZCP0845xttBrnbZU@kroah.com> (raw)
In-Reply-To: <f43f684c-8872-51c3-d72d-2d41b4a4e3e2@quicinc.com>

On Wed, Mar 29, 2023 at 03:46:45PM +0800, Linyu Yuan wrote:
> 
> On 3/29/2023 3:31 PM, Greg Kroah-Hartman wrote:
> > On Wed, Mar 29, 2023 at 03:00:54PM +0800, Linyu Yuan wrote:
> > > On 3/29/2023 2:53 PM, Greg Kroah-Hartman wrote:
> > > > On Mon, Mar 27, 2023 at 06:12:18PM +0800, Linyu Yuan wrote:
> > > > > It is known that dev_vdbg() macro can accept NULL or non-NULL dev pointer.
> > > > > 
> > > > > Add a struct device *dev member in struct ffs_data, set it to NULL before
> > > > > binding or after unbinding to a usb_gadget, set it reference of usb_gadget
> > > > > ->dev when bind success.
> > > > > 
> > > > > Then it can help replace private pr_vdebug() to dev_vdbg() consistently.
> > > > > 
> > > > > Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
> > > > > ---
> > > > > v3: new patch in this version
> > > > > 
> > > > >    drivers/usb/gadget/function/f_fs.c | 3 +++
> > > > >    drivers/usb/gadget/function/u_fs.h | 1 +
> > > > >    2 files changed, 4 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
> > > > > index a4051c8..25461f1 100644
> > > > > --- a/drivers/usb/gadget/function/f_fs.c
> > > > > +++ b/drivers/usb/gadget/function/f_fs.c
> > > > > @@ -1722,6 +1722,7 @@ static struct ffs_data *ffs_data_new(const char *dev_name)
> > > > >    		return NULL;
> > > > >    	}
> > > > > +	ffs->dev = NULL;
> > > > >    	refcount_set(&ffs->ref, 1);
> > > > >    	atomic_set(&ffs->opened, 0);
> > > > >    	ffs->state = FFS_READ_DESCRIPTORS;
> > > > > @@ -1831,6 +1832,7 @@ static int functionfs_bind(struct ffs_data *ffs, struct usb_composite_dev *cdev)
> > > > >    	}
> > > > >    	ffs->gadget = cdev->gadget;
> > > > > +	ffs->dev = &cdev->gadget->dev;
> > > > >    	ffs_data_get(ffs);
> > > > >    	return 0;
> > > > >    }
> > > > > @@ -1843,6 +1845,7 @@ static void functionfs_unbind(struct ffs_data *ffs)
> > > > >    		mutex_lock(&ffs->mutex);
> > > > >    		usb_ep_free_request(ffs->gadget->ep0, ffs->ep0req);
> > > > >    		ffs->ep0req = NULL;
> > > > > +		ffs->dev = NULL;
> > > > >    		ffs->gadget = NULL;
> > > > >    		clear_bit(FFS_FL_BOUND, &ffs->flags);
> > > > >    		mutex_unlock(&ffs->mutex);
> > > > > diff --git a/drivers/usb/gadget/function/u_fs.h b/drivers/usb/gadget/function/u_fs.h
> > > > > index 4b3365f..c5f6167 100644
> > > > > --- a/drivers/usb/gadget/function/u_fs.h
> > > > > +++ b/drivers/usb/gadget/function/u_fs.h
> > > > > @@ -146,6 +146,7 @@ enum ffs_setup_state {
> > > > >    struct ffs_data {
> > > > >    	struct usb_gadget		*gadget;
> > > > > +	struct device			*dev;
> > > > No, sorry, this is not correct.
> > > > 
> > > > You already have a struct device right there in the struct usb_gadget.
> > > > Use that one instead, as you are just setting this pointer to the same
> > > > value (see above where you set it.)
> > > 
> > > just want to use consistent dev_(v)dbg() related macro, to avoid reference
> > > usb_gadget->dev
> > > 
> > > when usb_gadget is NULL.
> > When will usb_gadget be NULL when you want to print out logging
> > messages?  You shouldn't be printing out anything during that time
> > anyway, right?
> 
> 
> when usb_gadget is NULL, there could be debug message because user space
> application
> 
> can start configure the ffs instance (like adb ...) for USB
> interface/endpoint/string descriptor.

But there is a "real" device down there somewhere as there would not be
any way for the driver to be able to talk to the hardware.  So please
use that.

> as dev_dbg related macro is safe to accept NULL, there is no need find out
> when will
> 
> usb_gadget is NULL and when will it a valid pointer.

Don't abuse dev_dbg() like this, that's not going to help out much
overall, and makes no sense to convert to something that is going to
print out incorrect messages (again, there is a device there.)

thanks,

greg k-h

  reply	other threads:[~2023-03-29  8:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 10:12 [PATCH v3 1/6] usb: gadget: ffs: remove ENTER() macro Linyu Yuan
2023-03-27 10:12 ` [PATCH v3 2/6] usb: gadget: f_fs: add more function with struct ffs_data *ffs parameter Linyu Yuan
2023-03-27 10:12 ` [PATCH v3 3/6] usb: gadget: f_fs: remove struct ffs_data *ffs from struct ffs_desc_helper Linyu Yuan
2023-03-27 10:12 ` [PATCH v3 4/6] usb: gadget: f_fs: add a device reference of usb_gadget->dev Linyu Yuan
2023-03-29  6:53   ` Greg Kroah-Hartman
2023-03-29  7:00     ` Linyu Yuan
2023-03-29  7:31       ` Greg Kroah-Hartman
2023-03-29  7:46         ` Linyu Yuan
2023-03-29  8:21           ` Greg Kroah-Hartman [this message]
2023-03-29  9:20             ` Linyu Yuan
2023-03-27 10:12 ` [PATCH v3 5/6] usb: gadget: f_fs: replace private pr_vdebug() with dev_vdbg Linyu Yuan
2023-03-29  6:55   ` Greg Kroah-Hartman
2023-03-29  7:01     ` Linyu Yuan
2023-03-29  7:31       ` Greg Kroah-Hartman
2023-03-27 10:12 ` [PATCH v3 6/6] usb: gadget: f_fs: show instance name in debug message Linyu Yuan
2023-03-29  6:54   ` Greg Kroah-Hartman
2023-03-29  7:11     ` Linyu Yuan
2023-03-29  7:37       ` Greg Kroah-Hartman
2023-03-29  7:42         ` Linyu Yuan
2023-03-29  8:21           ` Greg Kroah-Hartman
2023-03-29  8:46             ` Linyu Yuan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZCP0845xttBrnbZU@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=quic_linyyuan@quicinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).