Linux-USB Archive on lore.kernel.org
 help / color / Atom feed
From: Jun Li <jun.li@nxp.com>
To: Peter Chen <peter.chen@nxp.com>, Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"balbi@kernel.org" <balbi@kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>
Subject: RE: [PATCH 1/1] usb: gadget: core: wait gadget device .release finishing at usb_del_gadget_udc
Date: Sat, 1 Aug 2020 07:04:39 +0000
Message-ID: <VE1PR04MB65285671C1F7DD36DB2C48F3894F0@VE1PR04MB6528.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <DB8PR04MB7162CC76A1957F83F6079F688B4F0@DB8PR04MB7162.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Peter Chen <peter.chen@nxp.com>
> Sent: Saturday, August 1, 2020 2:54 PM
> To: Alan Stern <stern@rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; balbi@kernel.org;
> linux-usb@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 1/1] usb: gadget: core: wait gadget device .release finishing
> at usb_del_gadget_udc
> 
> 
> >
> > On 20-07-31 10:12:48, Alan Stern wrote:
> > > On Fri, Jul 31, 2020 at 02:06:20PM +0000, Peter Chen wrote:
> > > > On 20-07-31 14:25:20, Greg Kroah-Hartman wrote:
> > > > > On Fri, Jul 31, 2020 at 12:11:32PM +0000, Peter Chen wrote:
> > > > >
> > > > > Grab a reference from somewhere else and do not give it up for a
> > > > > long time.
> > > > >
> > > >
> > > > So wait_for_completion_timeout is suitable? The similar use case
> > > > is when we open the file at the USB Drive at Windows, and we click
> > > > "Eject", it will say "The device is currently in use", and refuse our "Eject"
> > > > operation.
> > > >
> > > > When we try to remove the gadget, if the gadget is in use, we
> > > > could refuse the remove operation, reasonable?
> > >
> > > No, the real solution is to fix the UDC drivers.  They need to
> > > allocate the gadget structure dynamically instead of reusing it.
> > > And they should have a real release routine that deallocates the gadget structure.
> > >
> > > Alan Stern
> >
> > So, the basic routine should like below. I thought the usb_gadget
> > should be deallocated before the UDC driver remove itself (UDC device
> > is the parent of usb_gadget device), I may not need to wrong about it,
> > it is just a memory region, it could release later.
> >
> > xxx_udc_release(struct device *gadget_dev) {
> > 	struct usb_gadget *gadget = container_of(gadget_dev, struct
> > 			usb_gadget, dev);
> > 	kfree(gadget);
> > }
> >
> >
> > xxx_udc_probe(pdev)
> > {
> > 	udc_priv_data = kzalloc(sizeof(*udc_priv_data), GFP_KERNEL);
> > 	gadget = kzalloc(sizeof(struct usb_gadget), GFP_KERNEL);
> > 	udc_priv_data->gadget = gadget;
> > 	...
> > 	usb_add_gadget_udc_release(&pdev->dev, gadget, xxx_udc_release);
> >
> > }
> >
> > At xxx_udc_remove(pdev)
> > {
> > 	usb_del_gadget_udc(udc_priv_data->gadget);
> > 	/* need to never reference udc_priv_data->gadget any more */
> > 	udc_priv_data other deinit;
> > 	kfree(udc_priv_data);
> > }
> >
> > Since all structures xxx_udc_release uses are common one, it could
> > replace usb_udc_nop_release at udc/core.c.
> >
> 
> Since gadget structure is allocated at UDC drivers, I think it should be freed at
> the same place. Current common release function at udc/core.c may not a good idea
> per our discussion.

Could all those allocation and free in UDC core? Have them in one central place
will ease/force UDC drivers to correctly handle this.

Li Jun
> 
> Peter

  reply index

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-31  9:59 Peter Chen
2020-07-31 11:55 ` Greg Kroah-Hartman
2020-07-31 12:11   ` Peter Chen
2020-07-31 12:25     ` Greg Kroah-Hartman
2020-07-31 14:06       ` Peter Chen
2020-07-31 14:12         ` Alan Stern
2020-07-31 23:42           ` Peter Chen
2020-08-01  6:53             ` Peter Chen
2020-08-01  7:04               ` Jun Li [this message]
2020-08-01 15:44               ` Alan Stern
2020-07-31 14:16         ` Greg Kroah-Hartman

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=VE1PR04MB65285671C1F7DD36DB2C48F3894F0@VE1PR04MB6528.eurprd04.prod.outlook.com \
    --to=jun.li@nxp.com \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=peter.chen@nxp.com \
    --cc=stern@rowland.harvard.edu \
    /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

Linux-USB Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-usb/0 linux-usb/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-usb linux-usb/ https://lore.kernel.org/linux-usb \
		linux-usb@vger.kernel.org
	public-inbox-index linux-usb

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-usb


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git