On Fri, 16 Dec 2005, David Brownell wrote: > Likewise for the others there. Feel free to check those into CVS > at sourceforge.
Okay. > You could force gadget zero to give out 62 byte strings to see if it > acts the same. That should help track the issue down. I just tried it, and the problem is confirmed. The string descriptor fetches time out. > I see the userspace "usb.c" test program doesn't support the control > OUT tests (usbtest case 14) that I usually use to make sure all > different lengths of control transfer behave for both IN and OUT. Would that help in this case? What's needed is a _short_ transfer that is a multiple of the maxpacket size. In test 14, the read length is the same as the write length. What did you think of the inode.c patch? Also, I forgot to mention before... There's also a problem with Get-Status requests (device status, that is). dummy_hcd does respond, probably because it includes full support for remote wakeup. net2280 does not; it delegates the request. (net2280 also delegates requests to set the remote-wakeup feature, which means the feature never gets enabled in the hardware.) None of the gadget drivers can handle it, nor does the usermode program. The requests time out, causing usbcore to assume the gadget is bus-powered. Looks like this needs to be added to most of the controller drivers. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
