Dear all, I'm currently using an ARM9 system called TMPA900 from Toshiba http://www.toshiba-components.com/microcontroller/TMPA900Family.html Linux-supported is maintained in an out-of-tree Git repository here http://git.labs.kernelconcepts.de/?p=topas.git;a=summary This SoC has an USB device controller which I want to use. The current driver can be found here: http://git.labs.kernelconcepts.de/?p=topas.git;a=blob;f=drivers/usb/gadget/tmpa9xx_udc.c;h=5c5bfcc9f7b0d08f5711457aca28bfe8d98a055c;hb=HEAD The datasheet can be found here, the device controller is explained in chapter 3.16: http://www.semicon.toshiba.co.jp/openb2b/relateddocument.jsp?did=19635&lang=en&pid=TMPA900CMXBG&returnFlag=1 Basic USB device support is working. I can load g_serial with "use_acm = 0" and then run minicom on both my target and the host system and send bytes back and forth. So far, so good. When using "use_acm = 1", however, things are different on Linux and Windows hosts. Under Linux, the communication works fine, but when using Windows, there are problems. The communication from the Windows host to my embedded target works fine, ie. I can see all characters typed. But the opposite direction is not working. Usually only the very first character makes it through, and then no other character can be seen. Here are some more observations: 0. Obviously the driver was cloned from the at91_udc driver, because a lot of the comments match. It's not some other USB host driver IP, so no other driver can be (re)used. The overall code quality is no very good. Kernel style is violated very often. Things from the AT91 driver is sometimes just commented out. It's hard to tell if things are there because of copy & paste or if they are really needed. Some hardware specific things are registered, but never actually used, for example the DMA handling. All in all this does not look very promising. 1. I enabled debugging in all modules that are used and added debug code here and there. When the first key is pressed, I can see that an USB packet is created, but apparently either not sent or not received. The next few keypresses seem to get queued up, some more keypresses and the driver will hang. I did not include the debug messages here, because they are specific for this driver. 2. Because there is likely an issue with the driver implementation, I went ahead and read http://www.linux-usb.org/usbtest/ -> "Testing USB Peripheral Controller. I used "usbtest" on the host to do the tests, but this immediately nuked the driver with a segmentation fault. Not a good sign. What to do now? I am looking for hints how to proceed. Especially because of observation 0, I am taking into consideration to do a rewrite of the driver. For that, I have been looking at existing drivers obviously, and "dummy_hcd" in particular. Is is a good idea to take the latter and add the hardware specific parts and remove the generic software emulation? Because I am in need for a better driver sooner or later, I am considering to give this development effort away to somebody that knows the details better than me. If you are interested in helping me out against payment of course, please drop me a line off-list. Best regards Michael. -- 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