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. First thoughts are that you'd need to be setting up a transfer just as the last active one completes. But I've a different scenario: C1) Active transfer completes, controller: C2) Writes to the event ring C3) Raises a hardware interrupt D1) Driver interrupt routing runs: D2) Completes the transfer D3) Requests another transfer D4) Calls prepare_ring() for it C4) Controller try to read the next ring entry. (or the read finally completes) and it gets one it owns. This would be timing critical, typically requiring a fast host and a slow(ish) controller. Note that the latency on PCIe accesses (eg the one the controller does to read the ring entry) is massive - think ISA bus speeds! so the host has plenty of time to execute a few 1000 instructions. What the NOP TRBs do is make it much more likely that a TB will start at the beginning of a ring segment. David -- 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
