On Sat, Oct 13, 2012 at 6:11 AM, Tilman Schmidt <tilman@xxxxxxx> wrote: > > I'm not sure I understand your argument. > > There are two cases I have to worry about: > (1) a reset triggered by int_in_work() > (2) a reset triggered by some other source external to the driver > > In case (1) the current design will deadlock because pre_reset() is > indirectly called from int_in_work() but calls cancel_work_sync() > which will wait for this very work item to complete. This would be > fixed by pre_reset() not calling cancel_work_sync() at all. Maybe you need to set a flag in int_in_work() to indicate that current reset is from itself, so you may fix both two cases. > int_in_work() will then run to completion without resubmitting > urb_int_in because it's already past that point once it calls > usb_reset_device(), so there's no conflict with post_reset() doing > that. > > In case (2) the current design will work fine, but if I remove the > call to cancel_work_sync() from pre_reset() there's a slight chance > that an uncompleted int_in_work() work item remains uncancelled. > So any part of int_in_work() might run asynchronously after > pre_reset(). The question is whether this might cause a problem. > > Which of the two cases does your argument address? I am saying the case 2, and the current design should be fine if the 1sec timeout can be tolerated in int_in_work(). You are right on case 1. Thanks, -- Ming Lei -- 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
