Lines Matching refs:completion

27 - Each URB has a completion handler, which is called after the action
29   context-pointer for passing information to the completion handler.
33   data to an endpoint while your driver handles completion of another.
50 // (IN) all urbs need completion routines
51 	void *context;                  // context for completion routine
52 	void (*complete)(struct urb *); // pointer to completion routine
54 // (OUT) status after each completion
99 returned to you in a completion callback.  It will automatically be
109 the desired transfer length, the completion  handler, and its context. 
141 look at that value except in your completion callback.
143 For isochronous endpoints, your completion handlers should (re)submit
158 returns; you must still wait for the completion handler to be called.
165 until after the URB has been returned and the completion handler
167 that if the completion handler or anyone else tries to resubmit it
172 time, and the completion handler may free the URB.  If this happens
179 completion handler, the handler must not take any lock that is held
191 by the completion handler.
194 1.7. What about the completion handler?
200 I.e., it gets the URB that caused the completion call. In the completion
203 information to the completion handler.
208 have transferred successfully before the completion was called.
215 In the current kernel, completion handlers run with local interrupts
217 local IRQs are always disabled inside completion handlers.
234 After completion, actual_length contains the actual transferred length and 
241 earlier, if you always keep at least one URB queued and your completion
259 restarted when they complete.  They end when the completion handler is
261 your completion handler must resubmit it.