On Fri, Jun 15, 2007 at 05:29:54PM -0400, Alan Stern wrote: > Now this would not allow us to do away with urb->status entirely. It > is still needed for storing unlink error codes, since URBs cannot be > given back immediately when they are unlinked. It's also needed by > usbcore, because endpoint_disable has to know which URBs have already > been cancelled. > > Still, it's better to have a field just for storing unlink codes than > one for overall status. In addition we won't need urb->lock any more, > since there won't be any contention between usbcore and the HCD for > setting the status. It's an overall win -- but I don't know enough > about the drivers to do it. What's your advice?
That sounds good to me. The primary use of the status field is to know if we need to resubmit it in the completion handler or not. The second major use is to see if it's still in use or not, and arguably, that's not safe to do so drivers need to do it outside of the urb structure. So, if we have some way to know if the urb has been cancelled, that solves the primary use. The "is this in flight" use might be good to have in the usbcore as it's needed a lot. I think I tried to do that in the past somehow but ran into problems with the host controllers and locking. thanks, greg k-h ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
