Hi, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Thu, 14 Dec 2017, Mathias Nyman wrote: > >> 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) >> >> Signed-off-by: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> > > 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). wouldn't we get EPIPE in cases where host's and device's data toggle/seqNum go out of sync? > 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! :-) It's mandatory for devices to support Clear-Halt as means to reset data toggle/SeqNum. If such controllers exist, they aren't certifiable IIRC. -- balbi
Attachment:
signature.asc
Description: PGP signature
