Messages in this thread | | | Date | Mon, 22 Dec 2014 10:34:30 -0600 | From | Felipe Balbi <> | Subject | Re: [PATCH] usb: gadget: udc-core: call udc_stop() before gadget unbind |
| |
On Mon, Dec 15, 2014 at 11:05:22AM +0100, Robert Baldyga wrote: > On 12/15/2014 06:13 AM, Peter Chen wrote: > > On Fri, Dec 12, 2014 at 02:17:28PM +0100, Robert Baldyga wrote: > >> As usb function drivers assumes that all usb request will be completed > >> before function unbind call, we should supply such behavior. In some > >> cases ep_disable() won't kill all request effectively, because some > >> IN requests can be in running state. In such situation it's possible > >> to have unbind function called before last request completion, which > >> can cause problems. > > > > Doesn't the function's disable/unbind should call usb_ep_dequeue to make > > sure the transfer has ended? > > USB function drivers like ECM or HID surely doesn't. It looks like > there's assumption that all requests will be completed by UDC driver.
that's a bug on those drivers :-)
> Function ep_disable() should complete requests in hardware driver, but > at least in DWC2 driver not all requests are completed at this stage
and that's a bug on dwc2 :-)
> (request which are in hardware FIFO are omitted to give them chance to > be transferred). Those requests are forced to complete in udc_stop()
that's wrong, we're disabling the endpoint anyway. Either dwc2 needs to wait_for_completion() or forcibly cancel the request. The bottom line is that control should not exit ep_disable() until all requests have been quiesced.
> function, and that's why it's needed to be called before unbind. > > > > > .udc_stop may stop the controller, and .unbind may still visit hardware. > > Hmm, indeed it can be problem.
yes, it will be :-)
-- balbi [unhandled content-type:application/pgp-signature] | |