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
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 usb_endpoint_xfer_isoc() call on line 2067 of
> gadget.c (as in my testing/next from
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
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 from today) won't even get executed, so
we're safe there.
>>>
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.
>>
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.
>>
>> Never will be executed? then we can
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,
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() (line 2025) at risk?
>
>
Hi,
On 26 May 2016 at 15:48, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> Hi Felipe,
>>
>> On 26 May 2016 at 14:22, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Baolin Wang writes:
When handling the
Hi,
On 26 May 2016 at 15:48, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> 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
Hi,
Baolin Wang writes:
> 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
Hi,
Baolin Wang writes:
> 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
>>> while
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
>>
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
>> while issuing usb_gadget_giveback_request()
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
> while issuing usb_gadget_giveback_request() function to release lock. So it
> will be
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
> while issuing usb_gadget_giveback_request() function to release lock. So it
> will be one bug to check the
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()
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()
18 matches
Mail list logo