hi 2011/12/30 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Thu, 29 Dec 2011, loody wrote: > >> Hi all: >> 1. if we don't call any unlink functions, such as usb_unlink_urb, >> the state of qh will keep QH_STATE_LINKED and linked after ehci->async. > > No. The qh will be unlinked a short time after its last URB completes. > An URB may complete because usb_unlink_urb was called, or it may > complete normally. > >> 2. if #1 is true, after calling usb_control_msg, the qh of ep0 will >> leave in ehci->async, right? > > No, it will be removed shortly after the URB completes. See the code > in the last few lines of qh_completions(), and see what scan_async() > does when qh->needs_rescan is set after qh_completions() returns. There are some things I cannot figure out. 1. needs_rescan is clear at the beginning of qh_completions(). why at the end of qh_completions, we need to check whether it is set as 1 or not for determining whether we should rescan? (I cannot find any function that will change this parameter while running qh_completions) 2. why we don't use atomic operation to set ehci->scanning? Doesn't it happen race condition when setting this flag? 3. I found there is a thread discussing about QH_STATE_COMPLETING. http://thread.gmane.org/gmane.linux.usb.general/20278 below is excerpted from above. ## ehci_urb_dequeue() will call qh_completions() when an interrupt URB is ## unlinked. While that URB is being given back, an IRQ might occur and ## scan_periodic() might then call qh_completions() for the same endpoint. At the beginning of ehci_urb_dequeue, we will "spin_lock_irqsave (&ehci->lock, flags);". Doesn't that mean the above behavior won't be possible? Thanks for all your kind help, -- 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
