Hi, On Thu, Aug 20, 2015 at 10:48:15AM -0400, Alan Stern wrote: > On Thu, 20 Aug 2015, Felipe Balbi wrote: > > > Hi, > > > > On Thu, Aug 20, 2015 at 04:25:08PM +0800, Peter Chen wrote: > > > Hi all, > > > > > > I have played usbtest and g_zero (f_sourcesink & f_loopback) to do > > > the tests between two boards these days, and have found some restrictions, > > > I list them here, and to see if they are common problems and can > > > be improved or not. > > > > first of all: why don't you just use the hcd-tests.sh shipped with the > > kernel ? Just start it with: > > > > ./hcd-tests.sh control in out halt > > > > > - Test 13 will fail due to there is pending IN request (f_sourcesink > > > will queue a request unconditionally at its completion), and udc driver > > > will run out error if that. udc driver must do that if it wants to > > > > wait, what ? test 13 works just fine here. (I'll try again in a few > > minutes just to make sure) > > It may depend on what UDC and what test device you use. Why ? Why would SET_FEATURE(HALT) fail ? I can only see it as a bug on the UDC driver. A bug which should be fixed. usbtest's halt set/clear test is pretty simple: 1. move data on EP to verify it's not halted 2. set halt 3. move data on EP to verify STALL is returned 4. clear halt 5. move data on EP to verify it's not halted I did fix that months ago on DWC3 because there was a bug on DWC3. MUSB was fixed years back too for a similar bug. > > > pass USB CV2.0 MSC TEST. (othwerwise, "Command Set Test - Device Configured" > > > will fail) > > > > Why would a pending struct usb_request in your queue fail USB CV ? > > _Lack_ of a pending request can cause the USB CV to fail. In Peter's > example, if you're testing a Mass-Storage gadget, USB CV requires that > there be a pending Bulk-OUT request when the gadget is idle (so that > the next SCSI command can be sent out). > > But if there's a pending usb_request on a bulk-OUT endpoint, will a UDC > driver be able to carry out a Set-Halt-Feature request from the host? > The answer isn't clear. And it's even worse for bulk-IN. how can USB CV even test that there is a pending request on the UDC's side ? Short of actually moving data on that pipe, there's not way. Also, when the Halt request comes, UDC must take care of doing whatever necessary to make halt work. If that means cancelling transfers on a particular EP, so be it. Give them back with -ESHUTDOWN or -EPIPE or whatever. Just look at usb_ep_set_halt()'s documentation which states that "drivers may need to empty the endpoint's request queue first". On top of that, we have the stall=0 flag for cases where the UDC really can't handle that halt request correctly. > > > - When using pattern = 1 as module parameters to compare the data, the > > > packet size must be same between host and device's. > > > > why ? > > The gadget stores the pattern data starting from 0 for each packet it > sends. But the host tests the pattern data starting from 0 only at the > beginning of the transfer; the host expects the pattern to continue > without resetting at packet boundaries (if the transfer length is > larger than the maxpacket size). then that's another bug which needs to be fixed :-) -- balbi
Attachment:
signature.asc
Description: Digital signature
