> Which doesn't make sense to me. I mean how can device send an event if it
> didn't yet receive a command.
> I'm not sure who's bug is it and is it a bug at all :)
Probably the device _has_ gotten the command. It just has not
yet acknowledged.
You need to queue events in this case.
> call it on ENXIO. usb-uhci and usb-ohci never call completion handler if
> submit_urb failed.
> Go figure when you have to free stuff and when you don't :).
>
> USB folks, comments ? How should we fix that ?
If submission fails, the usb layer must never use that urb again.
The HCDs are to blame.
> Also it's not clear whether completion handler can free urb or not.
> usb-uhci and usb-ohci don't seem to use
> urb after calling completion handler (except interrupt and ring transfers
> where you obviosly must not free urb)
> but uhci uses bunch of fields in urb after calling completion.
There are those who think that you can and those who think
that you can't.
If uhci touches it and you want your driver to work with uhci,
you must not free them or fix uhci.
> Current hci_usb driver does free urb in completion handler. Most of the
> Bluetooth bulk transfers look like:
> alloc_urb ---> submit_urb ---> urb->complete ---> free_urb
>
> USB folks, what is the general rule here ? Can completion handler free urb
> or not ?
> If urb is allocated dynamically it makes sense to allow completion handler
> to free it.
I may point out that it is very hard to write a disconnect() handler
if urbs can be freed in the completion handler, as you need
complicated locking.
You are doing yourself a favour if you don't do this.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
