On 13 October 2016 at 15:54, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> Hi,
>>
>> On 13 October 2016 at 15:08, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Baolin Wang writes:
@@ -1487,10 +1496,22 @@ static int dwc3_gadget_pullup(struct usb_gadget
*g, int is_on)
Hi,
Baolin Wang writes:
> Hi,
>
> On 13 October 2016 at 15:08, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Baolin Wang writes:
>>> @@ -1487,10 +1496,22 @@ static int dwc3_gadget_pullup(struct usb_gadget *g,
>>> int is_on)
>>>
>>> is_on = !!is_on;
>>>
>>> +try_again:
>>> spin_lock_irqsave(
Hi,
On 13 October 2016 at 15:08, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> @@ -1487,10 +1496,22 @@ static int dwc3_gadget_pullup(struct usb_gadget *g,
>> int is_on)
>>
>> is_on = !!is_on;
>>
>> +try_again:
>> spin_lock_irqsave(&dwc->lock, flags);
>> ret = dwc3_gad
Hi,
Baolin Wang writes:
> @@ -1487,10 +1496,22 @@ static int dwc3_gadget_pullup(struct usb_gadget *g,
> int is_on)
>
> is_on = !!is_on;
>
> +try_again:
> spin_lock_irqsave(&dwc->lock, flags);
> ret = dwc3_gadget_run_stop(dwc, is_on, false);
> spin_unlock_irqrestore(&
When we change the USB function with configfs dynamically, we possibly met this
situation: one core is doing the control transfer, another core is trying to
unregister the USB gadget from userspace, we must wait for completing this
control tranfer, or it will hang the controller to set the DEVCTRLH
Hi Felipe,
On 19 September 2016 at 19:52, Baolin Wang wrote:
> When we change the USB function with configfs dynamically, we possibly met
> this
> situation: one core is doing the control transfer, another core is trying to
> unregister the USB gadget from userspace, we must wait for completing
When we change the USB function with configfs dynamically, we possibly met this
situation: one core is doing the control transfer, another core is trying to
unregister the USB gadget from userspace, we must wait for completing this
control tranfer, or it will hang the controller to set the DEVCTRLH
7 matches
Mail list logo