Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1275131 > unrolled thread

[PATCH v7 4/4] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

Started byMarek Szyprowski <m.szyprowski@samsung.com>
First post2015-11-23 10:00 +0100
Last post2015-11-24 13:40 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH v7 4/4] usb: gadget: udc-core: independent registration of  gadgets and gadget drivers Marek Szyprowski <m.szyprowski@samsung.com> - 2015-11-23 10:00 +0100
    Re: [PATCH v7 4/4] usb: gadget: udc-core: independent registration  of gadgets and gadget drivers Alan Stern <stern@rowland.harvard.edu> - 2015-11-23 16:40 +0100
      Re: [PATCH v7 4/4] usb: gadget: udc-core: independent registration of  gadgets and gadget drivers Marek Szyprowski <m.szyprowski@samsung.com> - 2015-11-24 13:40 +0100

#1275131 — [PATCH v7 4/4] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

FromMarek Szyprowski <m.szyprowski@samsung.com>
Date2015-11-23 10:00 +0100
Subject[PATCH v7 4/4] usb: gadget: udc-core: independent registration of gadgets and gadget drivers
Message-ID<qxV8B-7TP-11@gated-at.bofh.it>
From: Ruslan Bilovol <ruslan.bilovol@gmail.com>

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.

Tested-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
[simplified code as requested by Alan Stern and Felipe Balbi,
 fixed checkpatch issues]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Peter Chen <peter.chen@freescale.com>
---
 drivers/usb/gadget/udc/udc-core.c | 41 ++++++++++++++++++++++++++++++---------
 include/linux/usb/gadget.h        |  2 ++
 2 files changed, 34 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/gadget/udc/udc-core.c b/drivers/usb/gadget/udc/udc-core.c
index f76ebc8..fd73a3e 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -51,8 +51,12 @@ struct usb_udc {
 
 static struct class *udc_class;
 static LIST_HEAD(udc_list);
+static LIST_HEAD(gadget_driver_pending_list);
 static DEFINE_MUTEX(udc_lock);
 
+static int udc_bind_to_driver(struct usb_udc *udc,
+		struct usb_gadget_driver *driver);
+
 /* ------------------------------------------------------------------------- */
 
 #ifdef	CONFIG_HAS_DMA
@@ -356,6 +360,7 @@ int usb_add_gadget_udc_release(struct device *parent, struct usb_gadget *gadget,
 		void (*release)(struct device *dev))
 {
 	struct usb_udc		*udc;
+	struct usb_gadget_driver *driver;
 	int			ret = -ENOMEM;
 
 	udc = kzalloc(sizeof(*udc), GFP_KERNEL);
@@ -403,6 +408,18 @@ int usb_add_gadget_udc_release(struct device *parent, struct usb_gadget *gadget,
 	usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
 	udc->vbus = true;
 
+	/* pick up one of pending gadget drivers */
+	list_for_each_entry(driver, &gadget_driver_pending_list, pending) {
+		if (!driver->udc_name || strcmp(driver->udc_name,
+						dev_name(&udc->dev)) == 0) {
+			ret = udc_bind_to_driver(udc, driver);
+			if (ret)
+				goto err4;
+			list_del(&driver->pending);
+			break;
+		}
+	}
+
 	mutex_unlock(&udc_lock);
 
 	return 0;
@@ -473,10 +490,14 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
 
 	mutex_lock(&udc_lock);
 	list_del(&udc->list);
-	mutex_unlock(&udc_lock);
 
-	if (udc->driver)
+	if (udc->driver) {
+		struct usb_gadget_driver *driver = udc->driver;
+
 		usb_gadget_remove_driver(udc);
+		list_add(&driver->pending, &gadget_driver_pending_list);
+	}
+	mutex_unlock(&udc_lock);
 
 	kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
 	flush_work(&gadget->work);
@@ -535,11 +556,7 @@ int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
 			if (!ret)
 				break;
 		}
-		if (ret)
-			ret = -ENODEV;
-		else if (udc->driver)
-			ret = -EBUSY;
-		else
+		if (!ret && !udc->driver)
 			goto found;
 	} else {
 		list_for_each_entry(udc, &udc_list, list) {
@@ -549,9 +566,11 @@ int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
 		}
 	}
 
-	pr_debug("couldn't find an available UDC\n");
+	list_add_tail(&driver->pending, &gadget_driver_pending_list);
+	pr_info("udc-core: couldn't find an available UDC - added [%s] to list of pending drivers\n",
+		driver->function);
 	mutex_unlock(&udc_lock);
-	return ret;
+	return 0;
 found:
 	ret = udc_bind_to_driver(udc, driver);
 	mutex_unlock(&udc_lock);
@@ -577,6 +596,10 @@ int usb_gadget_unregister_driver(struct usb_gadget_driver *driver)
 			break;
 		}
 
+	if (ret) {
+		list_del(&driver->pending);
+		ret = 0;
+	}
 	mutex_unlock(&udc_lock);
 	return ret;
 }
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index ce2188d..92467ee 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1014,6 +1014,7 @@ static inline int usb_gadget_activate(struct usb_gadget *gadget)
  * @driver: Driver model state for this driver.
  * @udc_name: A name of UDC this driver should be bound to. If udc_name is NULL,
  *	this driver will be bound to any available UDC.
+ * @pending: UDC core private data used for deferred probe of this driver.
  *
  * Devices are disabled till a gadget driver successfully bind()s, which
  * means the driver will handle setup() requests needed to enumerate (and
@@ -1076,6 +1077,7 @@ struct usb_gadget_driver {
 	struct device_driver	driver;
 
 	char			*udc_name;
+	struct list_head	pending;
 };
 
 
-- 
1.9.2

--
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/

[toc] | [next] | [standalone]


#1275492 — Re: [PATCH v7 4/4] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

FromAlan Stern <stern@rowland.harvard.edu>
Date2015-11-23 16:40 +0100
SubjectRe: [PATCH v7 4/4] usb: gadget: udc-core: independent registration of gadgets and gadget drivers
Message-ID<qy1nH-3Ia-17@gated-at.bofh.it>
In reply to#1275131
On Mon, 23 Nov 2015, Marek Szyprowski wrote:

> From: Ruslan Bilovol <ruslan.bilovol@gmail.com>
> 
> 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.
> 
> Tested-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
> [simplified code as requested by Alan Stern and Felipe Balbi,
>  fixed checkpatch issues]
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Tested-by: Peter Chen <peter.chen@freescale.com>

I missed this the last time through...

> @@ -403,6 +408,18 @@ int usb_add_gadget_udc_release(struct device *parent, struct usb_gadget *gadget,
>  	usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
>  	udc->vbus = true;
>  
> +	/* pick up one of pending gadget drivers */
> +	list_for_each_entry(driver, &gadget_driver_pending_list, pending) {
> +		if (!driver->udc_name || strcmp(driver->udc_name,
> +						dev_name(&udc->dev)) == 0) {
> +			ret = udc_bind_to_driver(udc, driver);
> +			if (ret)
> +				goto err4;
> +			list_del(&driver->pending);

This has to be list_del_init().  And somewhere in
usb_gadget_probe_driver() you need to do
INIT_LIST_HEAD(&driver->pending).

> @@ -577,6 +596,10 @@ int usb_gadget_unregister_driver(struct usb_gadget_driver *driver)
>  			break;
>  		}
>  
> +	if (ret) {
> +		list_del(&driver->pending);

Otherwise this will cause a crash or corrupt some random area of 
memory.

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/

[toc] | [prev] | [next] | [standalone]


#1276400

FromMarek Szyprowski <m.szyprowski@samsung.com>
Date2015-11-24 13:40 +0100
Message-ID<qyl35-86O-39@gated-at.bofh.it>
In reply to#1275492
Hello,

On 2015-11-23 16:32, Alan Stern wrote:
> On Mon, 23 Nov 2015, Marek Szyprowski wrote:
>
>> From: Ruslan Bilovol <ruslan.bilovol@gmail.com>
>>
>> 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.
>>
>> Tested-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>> Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
>> [simplified code as requested by Alan Stern and Felipe Balbi,
>>   fixed checkpatch issues]
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Tested-by: Peter Chen <peter.chen@freescale.com>
> I missed this the last time through...
>
>> @@ -403,6 +408,18 @@ int usb_add_gadget_udc_release(struct device *parent, struct usb_gadget *gadget,
>>   	usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
>>   	udc->vbus = true;
>>   
>> +	/* pick up one of pending gadget drivers */
>> +	list_for_each_entry(driver, &gadget_driver_pending_list, pending) {
>> +		if (!driver->udc_name || strcmp(driver->udc_name,
>> +						dev_name(&udc->dev)) == 0) {
>> +			ret = udc_bind_to_driver(udc, driver);
>> +			if (ret)
>> +				goto err4;
>> +			list_del(&driver->pending);
> This has to be list_del_init().  And somewhere in
> usb_gadget_probe_driver() you need to do
> INIT_LIST_HEAD(&driver->pending).
>
>> @@ -577,6 +596,10 @@ int usb_gadget_unregister_driver(struct usb_gadget_driver *driver)
>>   			break;
>>   		}
>>   
>> +	if (ret) {
>> +		list_del(&driver->pending);
> Otherwise this will cause a crash or corrupt some random area of
> memory.

'pending' handle is added to gadget_driver_pending_list in 
usb_gadget_probe_driver(),
then when udc is available it is removed from this list and bound to the 
given driver.
In usb_gadget_unregister_driver() the gadget is either unbound from the 
udc or if is
was not bound to any udc, removed from pending list. I see no need for 
adding
INIT_LIST_HEAD.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
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/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web