> > 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. Sure. I meant that control transaction has not completed. It doesn't make sense to start new transfer before acknowledging current one. Or does it ?
> > 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. Ok. uhci driver has to be fixed then. And fix is trivial. > > 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. What do other people think ? This should be fairly easily to fix. But the question is should we fix that or should we just say "no completion handler _must_ not free urb" because it's fundamentally wrong. > > 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. Not really. I have an skb queue of outstanding transfers. Each skb has a pointer to appropriate urb. On disconnect I just traverse the queue and synchronously unlink urbs and let the completion handler free recourses. So, simple skb queue locking is enough in my case. It be nice if usb core or HCD could unlink all outstanding urbs for this device on disconnect. (drivers have to do that anyway). In that case USB driver would not have to remember submitted URBs because HCD has them in it's queues. Max _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
