On Mon, 23 Apr 2012, Thomas Knauth wrote: > >> Is this the intended behavior? Any writes/reads falling short of the > >> gadget zero buffer length, cause testusb to hang (USB activity LED on > >> the net3380 is on, during this time though). > > > > No it shouldn't hang, but I must say I don't like how g_zero works > > today. It relies a lot on the peripheral controller being able to abort > > a transfer which was started by mistake. If you look at how USB classes > > are built, they all have some way to tell the other end transfer is > > over. > > > > Either they will negotiate a transfer size (e.g. Mass Storage with CBW) > > or they will use a ZLP to notify about the end of the transfer; but > > g_zero/usbtest has neither. > > This may actually be the explanation. The driver cannot tell whether > the request is finished or not if the size supplied to usbtest is a > multiple of the maximum packet size. Using, e.g., -s 511, works for > any value of -c. Using -s with g_zero buflen also works. Setting -s to > anything less than g_zero buflen being a multiple of the maximum > packet size, does not work. As far as I can tell from reading the > code, the driver does not know whether there will be more data for > this request, because req.actual < req.length (req.length defined by > g_zero buflen, req.actual defined by -s parameter to usbtest) and it > is not a short packet: > > is_short = (count == 0) || ((count % ep->ep.maxpacket) != 0); > > int retval = is_short || ((req->req.actual == req->req.length) && > !req->req.zero); > > I'm still unsure who is at fault here: the driver or g_zero/usbtest > and how best to fix this. Any suggestions? Why is this a problem? All that should happen is you transfer less data than g_zero expects. Either way, the transfer should succeed. 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
