Alan Stern <stern@...> writes: > > On Mon, 19 Apr 2010, Sumit Panchasara wrote: > > > can you describe the path for ioctl() from usb.c to gadgetfs.ko??? > > I mean which routine in gadgetfs.ko will get the ioctl() call from usb.c > > and its response back to usb.c.... ? > > > > I put print in ep_ioctl() at gadgetfs but it never comes there on call > > to ioctl() at usb.c!!! > > If you call ioctl() for the device file (endpoint 0), the call goes to > dev_ioctl(). For any other endpoint file, the call goes to ep_ioctl(). > > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@... > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Stumbled across this thread and have come to the same issue. I've traced through the ioctl() and found that it is hanging in the get_ready_ep() in the ep_ioctl(). Specifically that the lock is not able to be acquired on the ep1out. This would be the same lock acquired in the pending ep_read() sitting there for data from the host. What would the recommend way to 'kick' this read thread be to cause it to release the semaphore? Thanks, Ryan -- 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