On Wed, 22 Jul 2009, David Brownell wrote: > > While a QH might need all sort of complicated manipulations, right > > now I'm concerned only about linking and unlinking. > > Exactly. You can't escape those cases for any "live" QH. > Those "complicated manipulations" have to be the standard > case, or you will corrupt other data transfers. Do you have any particular examples of these manipulations in mind? qh_update() perhaps? I agree, it's important to be careful not to relink a QH while an URB is being given back. But is there anything else? > > If the QH is currently idle then ehci_urb_dequeue() doesn't need to > > call unlink_async() in the first place; it only needs to force a rescan > > (your (b) case below). > > No; if it's currently idle it's also currently empty, so > nothing would need to be done. (This should never happen, > since there'd be no URBs to unlink...) 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. > > If the QH _is_ currently linked then ehci_urb_dequeue() needs to unlink > > it -- forcing a rescan isn't enough (your (a) case). For this it does > > need to call unlink_async(), which does need to initiate the unlink. > > Except for the (b) subcase dealing with a halted QH that's > still linked ... Ah, good point. > If you're asking why it should be in qh_completions() rather > than say scan_async(), that's a different issue. In fact I > think scan_async() is a better spot; it's already got logic > to make that happen. The case you just raised shows that rescanning has to be implemented in qh_completions(), not scan_async(). This is because a halted QH with queued URBs gets restarted before qh_completions() returns, and we want the rescanning to occur before the restart. As for where an unlink should start... I can't see that it makes much difference, at least, not in cases where qh_completions() was called from scan_async(). And at every other place that calls qh_completions(), the QH is already IDLE -- with the exception of scan_periodic(), which uses a different unlinking mechanism anyway. So okay, I'll implement rescanning in qh_completions and unlinking in scan_async. > Just have unlink_async() set a flag. Maybe have qh_completions() > handle the (b) case if stopped; for sure, have scan_async() do the > honors for (a). Clear the flag after handling it. Right. 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
