On Tue, 8 May 2012, loody wrote: > 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) needs_rescan can be set to 1 by unlink_async(), which is called by ehci_urb_dequeue(), which can be called during usb_hcd_giveback_urb(), which is called by ehci_urb_done(), which is called by qh_completions(). > 2. why we don't use atomic operation to set ehci->scanning? > Doesn't it happen race condition when setting this flag? There are no races. ehci->scanning is used only while ehci->lock is held. > 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? It is possible because ehci_urb_done(), which is called by qh_completions(), does "spin_unlock (&ehci->lock);". 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
