Hi, 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. 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 ? -- balbi
Attachment:
signature.asc
Description: Digital signature
