Hello, I am working on a user-level USB peripheral device driver with a single pair of bulk in/out endpoints. It uses the gadgetfs() driver. I am initially running the usb.c example test program on gadgetfs, using the Windows USB 2.0 Command Verifier from usb.org. My target is a CM-T3730 board from compulab running a 3.0.32 kernel and a TimeSys root file system. It uses the musb-hdrc controller. When the USB20CV application attempts to execute the "Halt Endpoint Test", it tries to select interface 0, and a SET_INTERFACE request results in a call to ioctl ( ... GADGET_CLEAR_HALT) on the bulk endpoints. The ep_ioctl() function in drivers/usb/gadget/inode.c is called from the ep0 thread, which in turn calls get_ready_ep(), and ultimately, mutex_lock_interruptible(&epdata->lock); But the endpoint is managed by another thread which is blocked in ep_read() with the same endpoint mutex locked. This results in a deadlock, and the remainder of the Chapter 9 tests are failed. (The test fares slightly better with async enabled, but still fails on the unimplemented ep3 interrupt endpoint.) My driver's endpoint monitor threads suffer the same fate, as I do not currently use async I/O. The halt endpoint test is my only failure, though. I don't find any discussion of this problem on the archives -- is anyone aware of the issue? Is there a solution other than using async I/O? Can anyone suggest a potential solution for multiple threads with blocking I/O? How is the maturity of the Function File System composite gadget driver in comparison? Would it be better to convert to async I/O with gadgetfs, or to make the move to Function File System? Thank you in advance for your consideration. -- -dan'l Dan Rittersdorf, drittersdorf@xxxxxxxxx The information contained in this e-mail and any accompanying attachments may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email or any attachments. -- 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
