Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752760AbbBOXXG (ORCPT ); Sun, 15 Feb 2015 18:23:06 -0500 Received: from netrider.rowland.org ([192.131.102.5]:34363 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1750869AbbBOXXE (ORCPT ); Sun, 15 Feb 2015 18:23:04 -0500 Date: Sun, 15 Feb 2015 18:23:02 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Ruslan Bilovol cc: balbi@ti.com, , , , , Subject: Re: [PATCH v2 1/2] usb: gadget: udc-core: independent registration of gadgets and gadget drivers In-Reply-To: <1424041083-23694-2-git-send-email-ruslan.bilovol@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3417 Lines: 107 On Mon, 16 Feb 2015, Ruslan Bilovol wrote: > Change behavior during registration of gadgets and > gadget drivers in udc-core. Instead of previous > approach when for successful probe of usb gadget driver > at least one usb gadget should be already registered > use another one where gadget drivers and gadgets > can be registered in udc-core independently. > > Independent registration of gadgets and gadget drivers > is useful for built-in into kernel gadget and gadget > driver case - because it's possible that gadget is > really probed only on late_init stage (due to deferred > probe) whereas gadget driver's probe is silently failed > on module_init stage due to no any UDC added. > > Also it is useful for modules case - now there is no > difference what module to insert first: gadget module > or gadget driver one. > > Signed-off-by: Ruslan Bilovol > --- > drivers/usb/gadget/udc/udc-core.c | 77 +++++++++++++++++++++++++++++++++++++-- > 1 file changed, 74 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/gadget/udc/udc-core.c b/drivers/usb/gadget/udc/udc-core.c > index 5a81cb0..71b6942 100644 > --- a/drivers/usb/gadget/udc/udc-core.c > +++ b/drivers/usb/gadget/udc/udc-core.c > @@ -46,10 +46,18 @@ struct usb_udc { > struct list_head list; > }; > > +struct pending_gadget_driver { > + struct usb_gadget_driver *driver; > + char *udc_name; > + struct list_head list; > +}; Don't make this a separate structure. It should be embedded in the usb_gadget_driver structure. This will make a lot of the changes below much simpler. > @@ -288,6 +297,24 @@ int usb_add_gadget_udc_release(struct device *parent, struct usb_gadget *gadget, > > usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED); > > + if (!list_empty(&gadget_driver_pending_list)) { > + pending = list_first_entry(&gadget_driver_pending_list, > + struct pending_gadget_driver, list); > + > + if (pending->udc_name) { > + if (!strcmp(pending->udc_name, dev_name(&udc->dev))) { > + udc_bind_to_driver(udc, pending->driver); > + list_del(&pending->list); > + kfree(pending->udc_name); > + kfree(pending); > + } > + } else { > + udc_bind_to_driver(udc, pending->driver); > + list_del(&pending->list); > + kfree(pending); > + } This code can be simplified too: if (!pending->udc_name || strcmp(pending->udc_name, dev_name(&udc->dev) == 0) { ... > + } > + > mutex_unlock(&udc_lock); > > return 0; Don't you want to add a driver back to the pending list usb_del_gadget_udc() after the call to usb_gadget_remove_driver? > @@ -423,7 +450,27 @@ int usb_udc_attach_driver(const char *name, struct usb_gadget_driver *driver) > break; > } > if (ret) { > - ret = -ENODEV; > + struct pending_gadget_driver *pending; > + > + pending = kzalloc(sizeof(*pending), GFP_KERNEL); > + if (!pending) { > + ret = -ENOMEM; > + goto out; > + } > + pending->driver = driver; > + pending->udc_name = kstrdup(name, GFP_KERNEL); > + if (!pending->udc_name) { > + kfree(pending); > + ret = -ENOMEM; > + goto out; > + } Why do you need to copy the name? Just use the original. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/