Hi,
John Youn writes:
>>> You could try creating a composite device. Interface #1 having a
>>> single alt setting, interface #2 with multiple alt-settings. Start
>>> traffic to both interfaces, then start setting different alt-settings
>>> on interface #2.
>>>
>>> The problem is the databook doe
On 6/3/2016 3:55 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
> This reverts back to the original buggy behavior. This will fail when
> a SET_INTERFACE occurs multiple times.
>
> You can run testusb to see the failure:
> testusb -t 9 -c 5000 -s 2048 -a
I ca
Hi,
John Youn writes:
This reverts back to the original buggy behavior. This will fail when
a SET_INTERFACE occurs multiple times.
You can run testusb to see the failure:
testusb -t 9 -c 5000 -s 2048 -a
>>>
>>> I came up with something else for this. It's still unstable
On 6/2/2016 5:26 AM, Felipe Balbi wrote:
>
> hi,
>
> Felipe Balbi writes:
>>> This reverts back to the original buggy behavior. This will fail when
>>> a SET_INTERFACE occurs multiple times.
>>>
>>> You can run testusb to see the failure:
>>> testusb -t 9 -c 5000 -s 2048 -a
>>
>> I came up with
On 6/1/2016 11:38 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
However, I'm not aware of any issue with END_TRANSFER, could you let
me know how to reproduce it?
>>>
>>> it's a rare and difficult bug to reproduce. If you take my testing/next
>>> (I didn't check if it happens wi
On 6/1/2016 11:38 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
However, I'm not aware of any issue with END_TRANSFER, could you let
me know how to reproduce it?
>>>
>>> it's a rare and difficult bug to reproduce. If you take my testing/next
>>> (I didn't check if it happens wi
hi,
Felipe Balbi writes:
>> This reverts back to the original buggy behavior. This will fail when
>> a SET_INTERFACE occurs multiple times.
>>
>> You can run testusb to see the failure:
>> testusb -t 9 -c 5000 -s 2048 -a
>
> I came up with something else for this. It's still unstable and I need
hi,
John Youn writes:
> On 5/30/2016 7:19 AM, Felipe Balbi wrote:
>> Instead of looping through all endpoints when
>> enabling ep0, let's allow for each endpoint to set
>> its own xfer resource. This solves an issue which
>> happens when we issue END_TRANSFER due to a reset
>> interrupt. Endpoin
Hi,
John Youn writes:
>>> However, I'm not aware of any issue with END_TRANSFER, could you let
>>> me know how to reproduce it?
>>
>> it's a rare and difficult bug to reproduce. If you take my testing/next
>> (I didn't check if it happens with v4.7-rc1) - $subject and keep large
>> mass storage
On 5/31/2016 11:52 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
>> On 5/30/2016 7:19 AM, Felipe Balbi wrote:
>>> Instead of looping through all endpoints when
>>> enabling ep0, let's allow for each endpoint to set
>>> its own xfer resource. This solves an issue which
>>> happens when we
On 5/31/2016 11:52 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
>> On 5/30/2016 7:19 AM, Felipe Balbi wrote:
>>> Instead of looping through all endpoints when
>>> enabling ep0, let's allow for each endpoint to set
>>> its own xfer resource. This solves an issue which
>>> happens when we
Hi,
John Youn writes:
> On 5/30/2016 7:19 AM, Felipe Balbi wrote:
>> Instead of looping through all endpoints when
>> enabling ep0, let's allow for each endpoint to set
>> its own xfer resource. This solves an issue which
>> happens when we issue END_TRANSFER due to a reset
>> interrupt. Endpoin
On 5/30/2016 7:19 AM, Felipe Balbi wrote:
> Instead of looping through all endpoints when
> enabling ep0, let's allow for each endpoint to set
> its own xfer resource. This solves an issue which
> happens when we issue END_TRANSFER due to a reset
> interrupt. Endpoints will be left without a xfer
>
13 matches
Mail list logo
