Am Montag, 23. April 2012, 17:42:11 schrieb Alan Stern: > I don't like the idea of changing the status codes. It would mean > changing usb_kill_urb too. Why? > Instead of changing return codes or adding locks, how about > implementing a small state machine for each URB? > > Initially the state is ACTIVE. > > When the URB times out, acquire the lock. If the state is not > equal to ACTIVE, drop the lock and return immediately (the URB > is being unlinked concurrently). Otherwise set the state to > UNLINK_STARTED, drop the lock, call usb_unlink_urb, and > reacquire the lock. If the state hasn't changed, set it back > to ACTIVE. But if the state has changed to UNLINK_FINISHED, > set it to ACTIVE and resubmit. > > In the completion handler, grab the lock. If the state > is ACTIVE, resubmit. But if the state is UNLINK_STARTED, > change it to UNLINK_FINISHED and don't resubmit. > > This is a better approach, in that it doesn't make any assumptions > regarding synchronous vs. asynchronous unlinks. If you want, you could > have two different ACTIVE substates, one for URBs which haven't yet > been unlinked and one for URBs which have been. Then you could avoid > unlinking the same URB twice. That would work, provided we extend the status machine by an error code when resubmission is not desired and check for UNLINK_STARTED also when a timeout begins. But I wouldn't call that a simple solution. Regards Oliver -- - - - SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany - - - -- 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
