On Thu, 7 Feb 2008, Thomi Aurel RUAG A wrote: > Hi > > > Does this explanation help? > Yes, any explanation about the mechanisme of the processing of an usb transfer > will get me further on my understandings. > > > It _starts_ to handle the class request. If the request > > involves a data-OUT transfer, the setup function must call > > usb_ep_queue() to submit a request for that data. > The gadget setup handler have to memorize an "ongoing" request then?
Yes; it has to remember the values in the SETUP packet. > > 2.b and 2.c are completely wrong. Instead, the request's > > completion routine is called. That routine should finish > > processing the class request. > The completion callback of the previous "scheduled" usb_request will > finish the class request? Yes. > And its returnvalue defines the status > of the next STATUS stage? No, because the completion routine does not return a value. Some controller drivers allow the routine to indicate a failure status by stalling ep0 (usb_ep_set_halt), but other drivers do not allow this. It is a weakness in the Gadget API. > Thanks for your explanations You're welcome. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
