Hi, On 03/28/2014 10:45 AM, Oliver Neukum wrote: > Hans, > > it seems to me that there is a problem. > > uas_pre_reset() calls flush_work(). uas_do_work(), however > can reschedule itself if usb_submit_urb() fails. That opens > up the possibility that there's a permanent problem with > the device which causes an attempt to reset it and makes > usb_submit_urb() fail. What do you think? There are 2 reset paths here: 1) Reset from uas_eh_bus_reset_handler, in this case uas_abort_inflight() has run first, so there will be no work to be done at all, and the flush_work + usb_wait_anchor_empty_timeout are nops 2) Everything is working fine from the uas pov, but another driver for another interface of the device (ie usbhid) does a reset. This is why the block-reqs + flush_work + usb_wait_anchor_empty_timeout are there. To avoid in flight commands getting aborted in this case. Of course the problem you describe could still happen in case of 2) happening while at the same time for some reason usb_submit_urb() starts failing. This is not a problem either, as flush_work only guarantees finishing any work queued before calling it (*), so if uas_do_work re-queues itself because of submission failure, flush_work will still return after the initial uas_do_work run. And then usb_wait_anchor_empty_timeout will go into the timeout, and the reset can move along. Note that since we've the usb_wait_anchor_empty_timeout there (which we need anyways) the flush_work() is not really necessary, it is meant as a yield to uas_do_work to speed things up. Regards, Hans *) See: https://www.kernel.org/doc/htmldocs/device-drivers/API-flush-work.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
