On Wed, 1 Aug 2012, Dan Rittersdorf wrote: > 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. It looks like the lesson is not to have one thread accessing an endpoint at the same time as another thread issues a CLEAR_HALT. > (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? You can always interrupt the ep_read thread by sending it a signal. Then have it wait until the CLEAR_HALT is complete. There are some known problems related to locking in gadgetfs (it submits requests while holding a lock that the completion routine will take). So far nobody has cared about it enough to do a careful audit and fix. > 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? I don't know. > Thank you in advance for your consideration. Alan Stern -- 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
