Hi Felipe, > On Sun, Apr 22, 2012 at 05:52:11PM +0200, Thomas Knauth wrote: >> I am trying to develop a driver for the net2280 successor (USB 3380 >> from PLX). I'm fairly new to Linux driver development, so apologies >> for my ignorance. >> >> With some small modifications I was able to re-use the existing >> net2280 driver. However, when using usbtest with gadget zero I have >> the following behavior: >> >> $ ./testusb -s 512 -t 1 -c 2 hangs >> >> $ ./testusb -s 1024 -t 1 -c 2 succeeds, if gadget zero buflen is 1024 >> >> 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? > I have been meaning to change that for quite some time but I always get > caught up on other company tasks and it becomes difficult to handle all > of these details. > > Still, do not assume the problem is with g_zero/usbtest until you have > debugged it fully. Make sure your transfer completion IRQs are coming, > make sure you know where exactly the peripheral controller is hanging. > >> A single read/write (testusb ... -c 1) succeeds regardless of the size >> (matching or not matching the zero buffer length). > > Even if you do a single read/write which is larger than g_zero buflen ? usbtest -s cannot be greater than g_zero buflen. It is silently set to g_zero buflen. -- 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
