On Tue, 2011-03-29 at 11:56 -0700, Dmitry Torokhov wrote:
> > + /*
> > + * Barrier between reading the TRB_CYCLE (valid) flag above
> and any
> > + * speculative reads of the event's flags/data below.
> > + */
> > + rmb();
> > /* FIXME: Handle more event types. */
> > switch ((le32_to_cpu(event->event_cmd.flags) &
> TRB_TYPE_BITMASK)) {
>
> Isn't it the same memory that is being read the first time around? How
> reordering could happen here?
We don't try to enforce ordering specifically with the subsequent read
of the flags that is visible in the snipped above (indeed that's the
same address and so hopefully should be in program order), but all
subsequent reads which could have been performed speculatively such as
the rest of the event and including whatever other in memory information
the chip might have updated prior to sending the event.
Cheers,
Ben.
--
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
