Hi, Michael Grzeschik <mgr@xxxxxxxxxxxxxx> writes: >> > dwc3_gadget_ep_disable gets called before the last request gets >> > dequeued. >> > >> > In __dwc3_gadget_ep_disable all started, pending and cancelled >> > lists for this endpoint will call dwc3_gadget_giveback in >> > dwc3_remove_requests. >> > >> > After that no list containing the afterwards dequed request, >> > therefor it is not necessary to run the dequeue routine. >> > >> > Signed-off-by: Michael Grzeschik <m.grzeschik@xxxxxxxxxxxxxx> >> > --- >> > @Lars-Peter Clausen: >> > >> > This patch addresses the case that not queued requests get dequeued. >> > The only case that this happens seems on disabling the gadget. >> > >> > drivers/usb/dwc3/gadget.c | 3 +++ >> > 1 file changed, 3 insertions(+) >> > >> > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c >> > index 9a6f741d1db0dc..5d4fa8d6c93e49 100644 >> > --- a/drivers/usb/dwc3/gadget.c >> > +++ b/drivers/usb/dwc3/gadget.c >> > @@ -1609,6 +1609,9 @@ static int dwc3_gadget_ep_dequeue(struct usb_ep *ep, >> > >> > trace_dwc3_ep_dequeue(req); >> > >> > + if (!(dep->flags & DWC3_EP_ENABLED)) >> > + return 0; >> >> which driver is trying to call dequeue after the endpoint is disabled? >> Got some tracepoints of the problem happening? > > I see the case when using uvc-gadget. > > Look into uvc_v4l2_release in uvc_v4l2.c: > > uvc_function_disconnect > composite_disconnect > reset_config > uvc_function_disable->usb_ep_disable > > uvcg_video_enable > usb_ep_dequeue > dwc3_gadget_ep_dequeue Oh, I see what you mean. We get a disconnect, which disables the endpoints, which forces all requests to be dequeued. Now I remember why this exists: we giveback the requests from disconnect because not all gadget drivers will call usb_ep_dequeue() if simply told about the disconnect. Then UDC drivers have to be a little more careful and make sure that all requests are givenback. In any case, why is it a problem to call usb_ep_dequeue()? Is it only because of that dev_err()? We could just remove that message, really. Eventually, I want to move more of this logic into UDC core so udc drivers can be simplified. For that work, though, first we would have to add a "generic" struct usb_ep_hw implementation and manage list of requests as part of UDC core as well. -- balbi
Attachment:
signature.asc
Description: PGP signature