Hi, John Youn <John.Youn@xxxxxxxxxxxx> 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 >>> to debug further to figure out where we're wrong. But it seems to me >>> that we're following databook down to the last comma with patch >>> below. Note that we're partially reverting your original changes and >>> adding some extra knowledge about current configuration and interface, >>> then we only reassign transfer resources if those change. Care to have a >>> look? >> >> here's a version that passes testusb and normal enumeration with g_zero >> and g_mass_storage. After some experimenting, it seems like we should >> always MODIFY resource allocation, unless we're doing a SetConfiguration >> to the same configuration that is already chosen or a SetInterface to >> the same interface/alt-setting pair that's already being used. This is >> working for me. Can you test on your end too? > > Hi Felipe, > > You might be treading down a path we've already visited here :) :) > It looks like this patch will still fail the case with multiple > interfaces, with one or more having alt-settings. You will end up in a > situation where multiple endpoints are assigned the same transfer > resource which will cause failures. > > Unfortunately I don't have an easy test outside of our test > environment that exposes this. oh okay > 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 does not cover this condition. The > documentation will be fixed in 3.20a. > > Ravi Babu originally reported this and you can see discussion in this > thread: > > http://marc.info/?l=linux-usb&m=145396682025403&w=2 in that case, I'll just wait for your fix. But we really this fixed during this -rc cycle, so I can get my latest improvements (see testing/next) merged for v4.8. cheers -- balbi
Attachment:
signature.asc
Description: PGP signature
