On 10/29/2012 05:04 PM, Alan Stern wrote:
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.
That is true but you said on non-emulated HW that won't effect us
because real HW considers the scheduling interval of INT endpoints. So
it would be a problem with BULK which we hide here.
Alan Stern
Sebastian
--
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
