On Fri, 2 Sep 2011, Ming Lei wrote: > Hi, > > On Fri, Sep 2, 2011 at 9:58 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 2 Sep 2011, Ming Lei wrote: > > > >> On Wed, Aug 31, 2011 at 11:05 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > >> > > >> > You might want to remove also the first wmb() in qh_append_tds(). > >> > >> I think the first wmb() is used to order the two writing: > >> > >> � � � � � � � � � � � �qtd->hw_token = HALT_BIT(ehci); > >> � � � � � � � � � � � �wmb () > >> � � � � � � � � � � � �*dummy = *qtd; > >> > >> Since dummy has been in hw queue already and must see halt bit of hw_token > >> first, the barrier should be kept, otherwise the transaction represented by qtd > >> may be executed too early and qtd->hw_next is still not ready. > > > > The transaction represented by qtd can't be executed before the > > transaction represented by dummy, since qtd gets spliced at the end of > > the transaction list (it becomes the new dummy). �The transaction > > represented by dummy won't be executed until after dummy->hw_token is > > I understand dummy is already linked in ehci hw queue, so if > '�*dummy = *qtd;' is executed before 'qtd->hw_token = HALT_BIT(ehci);', > dummy will be executed by EHCI. That is the reason why I think the 1st > wmb() shouldn't be removed, right? When the CPU execute statements out of order, it is careful to make certain that the final results are the same as they would be if the statements were executed in order. Otherwise simple programs like x = 1; y = x + 2; wouldn't work -- y might not always get set to 3. In this case, dummy->hw_token will always be set to HALT_BIT(ehci) regardless of the order of execution. That's true even without the memory barrier. Without the memory, it is possible that qtd->hw_token won't get set to HALT_BIT(ehci) until after *dummy is written. But that doesn't matter, because the controller won't execute the *dummy transaction (since its HALT bit is set). Hence the controller won't see qtd until later, after the second memory barrier. 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
