On Wed, Apr 12, 2000 at 12:40:59AM +0000, Johan Verrept wrote:
> > No, except the urb->transfer_flags have USB_ASYNC_UNLINK set.
>
> hmm. I do not set that flag, but it seems to be called anyway...(
As noted in the response to Johannes, my first statement was wrong, the
completion is always called. The difference is only the transfer of
unfinished data if ASYNC is set.
> receive_data() )
> the status seemed to be set to -EILSEQ ?
> mayeb because of the queueing ?
> see attached dump.
>
> > > If it isn't, can I still call usb_unlink_urb() on it ?
> >
> > It should cause no harm, since unlink_urb should only do something if
> > urb->status is -EINPROGRESS. This is changed to -ENOENT during the
> > disconnect.
>
> So I should not release the memeory myself?
> not even when the result is actually -EILSEQ ?
Don't confuse unlink_urb and free_urb. unlink_urb simply (hum...) removes
the URB from the internal management and cancels outstanding transactions
associated with that URB. The URB structure is still allocated, but
the USB system won't touch it anymore. You have to free it explicitely
with free_urb.
> > Yes, it's experimental in usb-uhci and uhci. So it may work, but may also
> > cause unexpected behavior. In both cases, please inform us...
>
> 'key.
> no ohci support ?
AFAIK not yet. You should get -ENXIO if you try to submit a second URB to
the same endpoint without the QUEUE-flag or missing QUEUE-support.
--
Bye
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
