On Thu, 10 Feb 2005, Wolfgang M�es wrote: > My driver (auerswald) tries so send more than one URB to ep0 at a time! > But - I have learned that this does not work reliable, especially with > the UHCI hardware. This is mostly because of two facts: > > a) If there is a spike on the line, the retry mechanism of the host > controler is so fast that the retry has no effect - the spike is much > longer than the time needed for the 3 retries.
This will be true for bulk endpoints as well as for ep0. But maybe you don't care so much about losing bulk data... > So I think we will get a more reliable solution if the host controler > will get only one control URB at a time, with retries = 0, and a > timeout logik in software in the core. Do you think we should allow bulk URBs with retries = 0? Should there be a change to usbcore's API allowing drivers to specify unlimited retries for their URBs? Or maybe only for control URBs? Or should every non-iso URB always have unlimited retries? > b) IMHO, the endpoint queues are lacking an important feature: the > driver is not able to modify and control the queue. Restarting/Stopping > and inserting an URB in front of the queue are necessary to do a good > job for error recovery. Drivers _can_ stop and restart a queue; it happens every time you unlink an URB or an URB terminates with an error. (Okay, UHCI doesn't do this correctly when you unlink an URB, but it's going to be fixed eventually.) Inserting an URB at the front of a stopped queue is a luxury. You can live without it, by unlinking everything from the queue first. Besides, aren't you going to want to decide how to proceed based on the result of the URB inserted at the front? But you can't get a result without restarting the queue, and once it's restarted the queue won't stop after handling just that one URB. That's not what you want. (Actually it sounds like you want all the facilities provided by the block layer to be provided also by usbcore... :-) > Another lacking feature is un-stalling an > endpoint from inside the callback function.... before we can attempt to > retry the packet.... There's nothing unique to USB about this. No interrupt-time code is allowed to block or sleep, ever. > I have several installations with 24/7 runtime, and have spent far more > time on error recovery as on writing the driver.... I bet anyone who's ever written a high-reliability package would say the same thing. > IMHO it is OK to unlink all URBs of an endpoint at once (but not for > ep0), but this function should not be called unlink_urb() any more... Well, the whole point of doing this is that HCDs would no longer have to unlink individual URBs. Otherwise there's no real reason for it. So if the function isn't called unlink_urb any more then there wouldn't _be_ an unlink_urb, and we would have to change every USB driver. That's why I mentioned putting off API changes until 2.7. The nice thing about my suggestion is that it can be implemented now, without breaking anything. 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 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
