On Mon, 11 Apr 2005, David Brownell wrote: > > That's just it. The first part applies only when an URB completes with a > > hardware error, _not_ an unlink or kill! > > It was intended to cover _all_ fault reports. Unlink/kill is just > a software-induced fault.
Alright. I'll send an update that clearly states the first part refers only to hardware errors, not software-induced faults (unlink or kill). > And "normally" the action of an HCD for an unlink request must be > to deschedule/stop that endpoint's queue... <snip> > I suspect a lurking issue here may really be that UHCI still > has some issues with how it handles unlinking, which may not be > fixable until it actually has a solid notion of endpoint queue. > (Call that leftover 2.4-ism, if so. The whole notion of even > being able to unlink _just one_ request is very dubious; if you > look at the USB spec, it talks about killing _all_ IRPs at once.) Actually this is a new issue, not a lurking one. The whole point of that patch was because I'm going to make the majority of the UHCI driver run in a bottom half (a tasklet). This includes most of the work involved in submitting and unlinking URBs. The enqueue routine will accept an URB and just stick it on a list where the tasklet will see it later and put it on the schedule. Now consider what happens when an unlink occurs before the tasklet can run. The URB will never be put on the schedule at all! So there's no need to stop the queue. > > This may well occur before all the > > preceding URBs have terminated, since completion handlers are allowed to > > run out of sequence when an URB is unlinked. > > To safely run that out of sequence, its queue clearly stopped in some > sense. Not if the URB was never in the hardware queue to begin with. Yes, in some sense it is on a queue of URBs waiting for the tasklet to add them to the schedule, and _that_ queue will be stopped. But that queue isn't associated with the hardware or with any particular endpoint. So it's a question of how picky you want to get. <irrelevant comments snipped> > > According to the original wording the queue _would_ be stopped when the > > unlinked URB's completion handler was called, even though the hardware > > might not have reached the URB yet. > > Yes. How can you avoid stopping the queue in that case? If the hardware > is chewing through the queue, the _only_ way to control it is to stop > that endpoint queue. Otherwise the HC could be munching away on that > very transfer while the HCD was handing it back to some driver... I think the answer to that should be clear now. > > The old text said: > > > > But when an URB terminates with any fault (such as an error, or > > being unlinked) its queue stops... > > > > So the new text does describe different behavior from the old text. > > OK, so that new text is wrong then. The only problem case has ever > been (3b), where the URB completed (at the hardware level) before the > queue could be stopped. Nope, the new text describes exactly how the new driver will work. And it's correct. (3b) isn't a problem in the sense that we don't violate the guarantees made by the API. The queue _does_ stop, but it might not stop until after the hardware has begun working on the URB following the one that was unlinked. > So I'm not too worried about case (3b), although I think it should > get fixed someday ... by removing the "unlink one URB" semantics, > replacing them with a "kill this endpoint queue" request which is > not "buggy-as-designed" (because of a hardware race in the API). We discussed this not long ago, remember? People generally were against the idea of removing the "unlink one URB" operation. And there were a few cases where the "unlink one" semantics really are needed -- ep0 being one example. Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
