On Sun, 9 Apr 2006, David Brownell wrote: > On Tuesday 04 April 2006 12:10 pm, Alan Stern wrote: > > Dave: > > > > Here are the results from a few tests of my net2280 card, fresh as of this > > afternoon. > > > > (1) Testing with a Beagle analyzer showed that when running at full-speed, > > the net2280 always finishes a transfer on ep0 by NAKing the first > > status-stage transaction and sending the expected packet the second time. > > This is odd because the transfers were running without FSBR, so there was > > only one transaction per frame. The net2280 therefore had a millisecond > > to prepare for finishing the transfer, which should have been plenty of > > time. This was all stuff like descriptor fetches, nothing fancy. > > So it's sub-optimal but not incorrect?
Exactly. > That sounds like it should be > fixable by someone with time to apply. And possibly related to #2 below. Could be. > > (2) Editing zero.c to set various string descriptors to exactly 31 bytes > > showed that the net2280 did not respond correctly after all the data had > > been sent. A Get-String-Descriptor request for 255 bytes transferred 64 > > bytes in the first Data packet, and after that the net2280 NAKed all > > further IN packets until the transfer timed out. I verified this directly > > using the Beagle analyzer at full speed; at high speed usbmon showed the > > same results. > > OK, that's a bug and is incorrect. The configuration descriptor is also > 64 bytes, right? But it doesn't have that failure mode... No, the config descriptor transfer is a lot shorter. It comprises the config descriptor itself (9 bytes), the OTG descriptor (3 bytes), an interface descriptor (9 bytes), and two endpoint descriptors (14 bytes), for a total of 35 bytes. > > (3) After timing out on the Serial number descriptor transfer, Linux does > > a Get-Device-Status, which is a 2-byte transfer. The data was transferred > > correctly, but again the net2280 NAKed the status stage until the transfer > > timed out. Oddly enough, when I changed the Manufacturer string (which is > > fetched immediately before the Serial number string) to be 31 bytes long > > so that it timed out, and made the Serial number either 30 or 32 bytes, > > the Serial number transfer proceeded correctly. > > > > Clearly something is not working right. However I have no idea where to > > look or what to change in the driver. > > Net2280 can give IRQs for most EP0 events. I recall avoiding most NAK irqs, > since they are rarely meaningful. Grab the chip spec and watch the events > for EP0 as they're happening. When there's time to figure out the spec and the driver, and do some testing... Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
