On Thu, 23 Jul 2009, David Brownell wrote: > > Well, that's the thing. As of recently it _is_ possible for an IDLE QH > > to have URBs pending. This can happen if the QH is forced to be IDLE > > because it is waiting for a Clear-TT-Buffer to finish. > > I'd be tempted to update the state machine to include > a new QH_WAIT_TT_CLEAR state then ... transitions > presumably from QH_LINKED (via HALT/error) to that. > > As soon as the clear completes, the HALT bit in the > QH can be toggled and it could go back to QH_LINKED. > I can't see any reason to require such QH ops to go > through the unlink process; they're supposed to be > very quick, yes? That'd preserve the invariant that > QH_IDLE implies TD-list-is-empty. I don't think this is such a good idea... The state machine currently requires that a halted QH has to pass through the IDLE state before returning to LINKED. According to your own comments: /* We won't refresh a QH that's linked (after the HC * stopped the queue). That avoids a race: * - HC reads first part of QH; * - CPU updates that first part and the token; * - HC reads rest of that QH, including token * Result: HC gets an inconsistent image, and then * DMAs to/from the wrong memory (corrupting it). Why change this policy in cases where a Clear-TT-Buffer just happens to be needed? Now, there is a second reason (besides a transfer error causing a halt) why a Clear-TT-Buffer might be needed. Namely, that an active URB was dequeued and the results of its last transaction are still sitting in the TT buffer. But of course, in this case the QH is already in the IDLE state. 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
