On 12/06/16 14:36, Peter Chen wrote:
> On Fri, Jun 10, 2016 at 04:07:22PM +0300, Roger Quadros wrote:
>>  
>> +/**
>> + * usb_otg_add_gadget_udc - adds a new gadget to the udc class driver list
>> + * @parent: the parent device to this udc. Usually the controller
>> + * driver's device.
> 
> It seems it should be udc device

Parent and udc->dev are not the same right?

I guess i'll omit the second statement to avoid confusion. So.

@parent: the parent device to this udc.

> 
>> +/* udc_lock must be held */
>>  static int udc_bind_to_driver(struct usb_udc *udc, struct usb_gadget_driver 
>> *driver)
>>  {
>>      int ret;
>> @@ -1282,17 +1449,26 @@ static int udc_bind_to_driver(struct usb_udc *udc, 
>> struct usb_gadget_driver *dri
>>      ret = driver->bind(udc->gadget, driver);
>>      if (ret)
>>              goto err1;
>> -    ret = usb_gadget_udc_start(udc);
>> -    if (ret) {
>> -            driver->unbind(udc->gadget);
>> -            goto err1;
>> +
>> +    /* If OTG/dual-role, the otg core manages UDC start/stop */
>> +    if (udc->gadget->otg_dev) {
>> +            mutex_unlock(&udc_lock);
>> +            usb_otg_gadget_ready(udc->gadget, true);
>> +            mutex_lock(&udc_lock);
>> +    } else {
>> +            ret = usb_gadget_udc_start(udc);
>> +            if (ret) {
>> +                    mutex_unlock(&udc_lock);
>> +                    driver->unbind(udc->gadget);
>> +                    goto err1;
>> +            }
>> +            usb_udc_connect_control(udc);
>>      }
>> -    usb_udc_connect_control(udc);
>>  
>>      kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE);
>>      return 0;
>>  err1:
>> -    if (ret != -EISNAM)
>> +    if ((ret != -EISNAM) && (ret != -EPROBE_DEFER))
> 
> It seems it will not introduce -EPROBE_DEFER with your changes
> in udc_bind_to_driver
> 

Good catch. Left over bit when I moved defer probing out of here.

--
cheers,
-roger

Reply via email to