On Thursday 14 March 2002 01:39, Maksim Krasnyanskiy wrote:
> > > 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 ?
Somebody in the device firmware has exchanged two lines.
You have to deal with it. The world is unfair :-)
> >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.
Could you point me to the code ?
I can see no way you could unlink synchronously.
You need to hold an irqsafe spinlock on that queue while you
call usb_unlink_urb and that pretty much rules out doing
a synchronous unlinking.
> 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.
There is an idea.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
