usb: usbtest: Add TEST 29, toggle sync, Clear toggle between bulk writes
Hi,
Quoted 27 lines · Mathias Nyman
Quoted 26 lines · Alan Stern
Quoted 17 lines · Mathias Nyman
Clear Feature Endpoint Halt should reset the data toggle even if the endpoint isn't halted. Host should manage to clear the host side data toggle to keep in sync with the device.
Test by sending a "3 data packet URB" before and after clearing the halt. this should create a toggle sequence with two consecutive DATA0 packets.
A successful test sequence looks like this
ClearFeature(ENDPOINT_HALT)- initial toggle clear
DATA0 (max packet sized)
DATA1 (max packet sized)
DATA0 (zero length packet)
ClearFeature(ENDPOINT_HALT)- resets toggle
DATA0 (max packet sized), if clear halt fails then toggle is DATA1 DATA1 (max packet sized)
DATA0 (zero length packet)Quoted 1 line
Signed-off-by Mathias Nyman <[email protected]>This test is a little unusual in that it doesn't contain a way to detect failures. That is, you can't tell from the test results whether the device and the host behaved the way they are supposed to (in the case of the host, you could use a USB analyzer to find out).
Quoted 8 lines
Quoted 3 lines
Also, some devices don't handle Clear-Halt requests properly if the endpoint isn't already halted. Presumably people wouldn't use one of those devices for this test! :-)
I was hoping that the device (dwc3 with zero gadget in my case) would somehow react if the host sends a DATA1 packet right after
ClearFeature(ENDPOINT_HALT), but turns out this device accepts it and continues to work just fine. So I ended up looking at the traffic with
that's because we prevent clear halt when endpoint is not halted. That was changed when a problem was found when enumerating against macOS. It may be that we're actually hiding an IP bug by doing that, however I never got an argument strong enough to revert the commit.
This, may just be the strong argument I need :-)