> But I have a problem with usb_unlink_urb() and resubmitting, as you
> suggests.
>
> First of all, usb_unlink_urb() comes in two flavours, asynchronous and
> synchronous. If I use asychronous unlink, it may well be the aim of the
> device driver writer to do a resubmit in the completion function as a
> result of the unlink! (perhaps to implement an external timeout/retry for
> an urb).
>
> And the same completion handler should not be able to do a resubmit if the
> unlink is synchronous?
There's no such use as far as I am aware. We will add an API call to "delock"
an URB, if need be and if people feel they might need it, we can do it now.
> Your design requires an API function (usb_submit_urb()) to fail because of
> the context of the call.
Yes. That's what the commonest use of usb_unlink_urb(), in disconnect(),
profits from.
> > The driver should not need to care. It should have only to call
> > usb_unlink_urb() and know that the URB is absolutely eradicated.
> > The core won't touch it any more, you can free all buffers associated,
> > no completion handler is running and the completion handler won't
> > resubmit.
> > That's what the device drivers really need.
>
> Because the completion handler is called as a result of an asynchronous
> unlink, it should be also called as the result of an sychronous unlink.
> Same behaviour, every time, please!
Yes, absolutely. Either the completion handler is called, or usb_unlink_urb()
returns an error code. All we add is that after a synchronous unlink returns
no completion handler is running, whether there's an error or not.
(Unless you call before submission. We can do nothing about it.)
> Of course, the completion handler should know that it was called because of
> unlink(). So it can avoid a resubmit, and we need no extra device driver
> specific flags.
We do not change status reporting to the completion handlers in urb.status.
But there's the issue of usb_unlink_urb() during the completion handler
but before a possible resubmission. Our solution is to fail the resubmission
in that case. Otherwise you need a flag, a spinlock and synchronisation
between the completion handler and the thread calling usb_unlink_urb().
> To avoid races, the unlink function and the completion handler need to have
> exclusive access to the urb. (Spinlock?).
>
> > Correct. There are two cases of usb_unlink_urb() being called on an
> > unlinked URB.
> > Calling it on an URB that is not yet linked is a driver bug.
> > Calling it on an URB that is no longer linked is not an error,
> > it's unavoidable.
>
> How do you differ between the two cases? They may be the same.
How so?
Regards
Oliver
-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
