On Mon, 3 Dec 2018, Anurag Kumar Vulisha wrote: > >First of all, if some sort of deadlock causes a transfer to fail to > >complete, the host is expected to cancel and restart it. Not the > >gadget. > > > > Thanks for spending your time in reviewing this patch. The deadlock > is a very rare case scenario and is happening because both the gadget > controller & host controllers get out of sync and are stuck waiting for the > relevant event. For example this issue is observed in stream protocol where > the gadget controller is waiting on Host controller to issue PRIME transaction > and Host controller is waiting on gadget to issue ERDY transaction. Since > the stream protocol is gadget driven, the host may not proceed further until it > receives a valid Start Stream (ERDY) transaction from gadget. That's not entirely true. Can't the host cancel the transfer and then restart it? > Since the gadget > controller driver is aware that the controller is stuck , makes it responsible > to recover the controller from hang condition by restarting the transfer (which > triggers the controller FSM to issue ERDY to host). Isn't there a cleaner way to recover than by cancelling the request and resubmitting it? > >Second, if a request timer expires and the request is cancelled, the > >gadget driver's completion handler will be called. This is not what > >you want if the UDC core is going to resubmit the request > >automatically. > > > >Third, if a request timer expires and the timer handler calls > >usb_ep_dequeue() followed immediately by usb_ep_queue_timeout(), the > >resubmit will probably fail because the dequeue won't have completed > >yet. > > > >Fourth, the patch contains a race between the timer expiring and the > >request completing. > > Thanks for correcting, I agree with you on all the above 3 cases that the > resubmission of the request should only be done from the class driver and > the udc core should simply dequeue the request on timeout. I am not sure > why I haven't seen any issue while testing on this patch series. I will modify > the code to handle the resubmitting of requests properly. How can the gadget driver know what timeout to use? The host is allowed to be as slow as it wants; the gadget driver doesn't have any way to tell when the host wants to start the transfer. Alan Stern
