On Mon, 29 Oct 2012, Sebastian Andrzej Siewior wrote: > > Sorry, I've forgotten the context for this change. (We discussed > > something and I suggested the right solution would be to add an > > endpoint-specific data structure like a QH on the host side, but I > > can't remember the details.) > > > > Remind me please, what is the problem you need to solve? > > Sure. rmmod g_ncm after ifconfig usb[01] resulted in a busy loop. The > problem was that the gadget side disabled endpoints and the host side > had requests queued. The timer found a request and gave it back with > -EPROTO because it did not find an endpoint (it was disabled). The give > back of the INT packet resulted in a re-queue. So we had another > request in the queue to process and because we did not find an endpoint > we gave it back with -EPROTO and the INT packet � Was that really the problem? My memory is not what it was three weeks ago... If so, there's a simpler solution. The list_for_each_entry_safe() loop in dummy_timer() should not consider URBs that were added after the loop started. That ought to be easy enough to implement. (One solution: Increment a counter each time dummy_timer() runs, and store a copy of the counter value in each urbp during submission. Exit the loop when the stored counter value in urbp is equal to the current counter.) This will prevent you from getting into an infinite loop in atomic context. Of course, the resubmission problem would still exist, but that's true with non-emulated gadgets too. Alan Stern -- 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
