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. Alan Stern