On Fri, Jan 18, 2019 at 11:52:57AM -0500, Alan Stern wrote: > On Fri, 18 Jan 2019, Paul Elder wrote: > > > > > I meant the functions (procedures) in the function driver, so the setup > > > > handler (uvc_function_setup), the completion handler > > > > (uvc_function_ep0_complete), and the status sender (uvc_send_response), > > > > although the last one actually sends the data stage for control IN. > > > > So after the status is sent on the uvc gadget driver's end, its > > > > completion handler is called again without the setup handler being > > > > called beforehand and I cant figure out why. > > > > > > Isn't this what you should expect? Every usb_request, if it is queued > > > successfully, eventually gets a completion callback. That promise is > > > made by every UDC driver; it's part of the gadget API. So for a > > > control transfer with a data stage, you expect to have: > > > > > > Setup handler called > > > Data-stage request submitted > > > Data-stage request completion callback > > > Status-stage request submitted > > > Status-stage request completion callback > > > > > > Thus, two completion callbacks but only one setup callback. > > > > omg how did I not notice this :/ > > > > I guess I have to fix the uvc function driver so it works with that. > > musb doesn't call the status stage completion callback though; not that > > it does anything so it seems fine to me, but indeed the function driver > > has to be ready for it if it is called. > > musb _has_ to call the status-stage completion callback. As just one > reason, if the explicit_status flag isn't set then that callback is > responsible for deallocating the status request. Without it, the > status request will leak. Ah, I see what you mean. I forgot about that because we reuse the request in uvc gadget. I'll have to add the status stage completion callback to musb too, then. Thanks, Paul
