On 26 May 2016 at 18:27, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> On 26 May 2016 at 17:45, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Baolin Wang writes:
>>>
>>>
>>>
> Also note that the
Hi,
Baolin Wang writes:
> On 26 May 2016 at 17:45, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Baolin Wang writes:
>>
>>
>>
Also note that the usb_endpoint_xfer_isoc() call on line 2067 of
gadget.c (as in my testing/next
On 26 May 2016 at 17:45, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>
>
>
>>> Also note that the usb_endpoint_xfer_isoc() call on line 2067 of
>>> gadget.c (as in my testing/next from today) won't even get executed, so
>>> we're safe there.
>>
Hi,
Baolin Wang writes:
>> Also note that the usb_endpoint_xfer_isoc() call on line 2067 of
>> gadget.c (as in my testing/next from today) won't even get executed, so
>> we're safe there.
>
> Never will be executed? then we can remove the
> usb_endpoint_xfer_isoc()
Hi Felipe,
On 26 May 2016 at 14:22, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> When handling the endpoint interrupt handler, it maybe disable the endpoint
>> from another core user to set the USB endpoint descriptor pointor to be NULL
>>
When handling the endpoint interrupt handler, it maybe disable the endpoint
from another core user to set the USB endpoint descriptor pointor to be NULL
while issuing usb_gadget_giveback_request() function to release lock. So it
will be one bug to check the endpoint type by usb_endpoint_xfer_xxx()