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
Attachment:
signature.asc
Description: Digital signature
