On Fri, 15 Jun 2007, Greg KH wrote:
> 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.
I would have said that the primary use of the status field is to know
whether the transfer succeeded! On the other hand the actual_length
field does tell you most of what you need to know.
> 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.
A problem is that the "in-flight" status can change at any time, so
without some form of synchronization the value is almost useless. And
remember, even if an URB is no longer in flight it might still be in
use, since the completion handler could still be running.
Which reminds me... Earlier we discussed the main barrier against
having HCD's allocate their own URBs (including the necessary private
region), which was that some drivers maintain pools of URBs for use
with devices on several different buses.
This can lead to an unexpected problem with either usb_unlink_urb() or
usb_kill_urb(). Here's what can happen:
CPU 0 CPU 1
----- -----
Submit URB
Call usb_kill_urb
URB completes normally
URB is returned to the pool
URB is taken from the pool
and used for a different
device
The URB is killed
In other words, if you kill an URB it's not safe to reuse it until the
kill has completed. It is another reason for drivers not to maintain
common pools of URBs for multiple devices.
Alan Stern
-------------------------------------------------------------------------
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
