On Thu, 29 Nov 2012, amit nagal wrote: > On Wed, Nov 28, 2012 at 9:58 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > Vivek and Amit, are you two copies of the same person? > No . Actually vivek's post to linux-usb forum failed . so i ended up > posting for him. > sorry for inconvinience . No problem. > >> As urb processing is complete by the > >> time urb->complete() > >> is called , I think urb->use_count should be decremented first > >> followed by urb completion handler call as below :- > > > > This is wrong. Processing continues during urb->complete, which may > > even resubmit the URB. > > but completion handler is called when urb is completed . Also with > resubmit of URB new usb i/o will take place implying previous usb i/o > is already completed . i am still not clear with the need to decrement > urb->use_count > after completion handler . can u please let us know a bit more > regarding urb->use_count usage . There's a difference between an URB and a USB transfer. The transfer completes before the completion handler runs, but the URB is still in use -- and in fact the same URB can be used for many transfers. The period of time covered by each increment of urb->use_count goes from submission until after the completion handler returns. > Also In usb.h comments for urb->use_count are "/* concurrent > submissions counter */ " . > does usbcore allows for concurrent submission of same urb ? This refers to resubmissions made by the completion handler. The use_count is still 1 while the handler runs, and resubmission increases the use_count to 2. That's because there are two concurrent usages going on: one for the transfer the just ended and one for the transfer that's just starting. > > Now, maybe your problem is that somehow urb->reject is getting set to 0 > > at the wrong time. You should check its value as well as the value of> urb->use_count. > Thanks for pointers . we will definately look into both fields values . Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
