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. > > 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. > > - 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). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
