On Fri, 9 Apr 2004, David Brownell wrote: > The now-more-common state is "sitting on UHCI complete_list". > Subcases include "unlinked", "shut down", "normal completion", > and "I/O error".
That's not quite right. Membership in the complete_list is pretty short-lived (entirely in_interrupt). Maybe you're thinking of the urb_remove_list? That only includes "unlinked" and "shut down", not the other subcases. > (Neither OHCI nor EHCI have such a state; it comes from the > QH-per-URB approach.) I don't think that's right, for either list. The complete_list itself is unnecessary; using it was just a form of optimization in earlier versions of the driver (that's my guess). It meant the driver could avoid releasing and reacquiring all those different spinlocks each time it gave back an URB. The need for the urb_remove list arises because the driver can only synchronize with the hardware at SOF; when an URB is unlinked it has to remain on that list until the next synchronization point. There's no connection with QHs. > > UHCI _had_ implemented disable_endpoint and someone encountered that race > > while closing the bluetooth device, it would have been impossible to > > reproduce or find the error. > > If it was "impossible" it wouldn't be a problem though would it? :) Right, I should have said "nearly impossible" -- that can mean whatever you want! Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
