On Wed, 15 Jan 2014, David Laight wrote: > I have a theory, I'll try to write a non-invasive patch. > > In spite of the comments and some code paths inc_enq() is only > called by (and has only ever been called by) queue_trb(), so > is only called for transfer and command rings. > > It takes care to avoid advancing past the LINK TRB. > The coding would be much simpler if it did, and I postulate > that the reason for this was that some hardware didn't like it. > In particular doing so with TRB_CHAIN set could well cause issues. > > So assume that the ASMedia controller doesn't like LINK TRB if the > link-to trb can't be processed. If the hardware test vectors > don't test this is could easily be a bug. > > Now, under normal conditions the controller will be idle and > won't look at the ring until the doorbell is rung - by which > time the ownership bits are set through to the end of the command. > > But consider what happens if the controller is active and > is looking for work.... > > prepare_ring() will change the ownership bit of any NOP TRB > it writes and of the LINK TRB. The ownership on the first > transfer TRB is set much later. > > This makes it not impossible for the controller to find a TRB > it doesn't own after processing a LINK TRB.
Doesn't this mean you shouldn't change the ownership of a LINK TRB until after you change the ownership of the TRB it points to? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
