> > You're speaking figuratively, right? _You_ don't complete the request, > g_file_storage does. Or maybe the udc driver does; it's not clear which > you mean. So when you say you don't understand what to do, do you mean > that _you_ don't understand or the udc driver doesn't understand?
I mean that I didn't understand my problem... I know that the udc has a lot of work to do! > > message too (maybe from the host)... usb_control/bulk_msg: timeout! > > That particular CBW will cause g_file_storage to stall the bulk-in > endpoint, unless you invoke it with the "stall=no" parameter. Maybe your > udc driver has problems implementing the stall? > I'll take a look for stall endpoint. I think that's not really implemented. > This may be a failure of your udc to complete the status stage of the > device reset control message. Or maybe g_file_storage is hung, waiting > for your udc to carry out the stall. > > > Also, you can get more information by editing the gadget/file-storage.c > source file and enabling the various debugging options, if you haven't > done this already. Yeah I added some printk() some places in UDC and file-storage.c too. I'll continue to do it to find the source of my problem! > > Alan Stern > > ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
