On Wednesday 30 March 2005 3:38 pm, Alan Stern wrote: > On Wed, 30 Mar 2005, David Brownell wrote: > > > > This is disturbing. There already is a section of code in usb-storage > > > that calls usb_clear_halt at a spot where only _one_ type of device (an > > > old model ZIP drive) is known to halt its bulk endpoints. I had thought > > > that for every other device this wouldn't cause a problem; apparently I > > > was wrong. > > > > It's probably sufficient that the queue be inactive/empty, in this case. > > Maybe. Your problem with g_zero was caused by the fact that it always > queues an IN stream of zeros?
Not necessarily zeroes; it can also send other data patterns. But yes: the issue is that the queue is never empty, unless the gadget driver explicitly empties it. It will empty the queue for SET_INTERFACE. But CLEAR_HALT is a lower level request, often handled in hardware ... it doesn't involve any handshake with upper level code. So it's always safe if that upper level code has successfully set the halt, but not otherwise. > Bear in mind that the Mass Storage CB[I] protocol _requires_ the host to > issue CLEAR_HALT at times for pipes that have not sent a stall token (the > reason being that the device may have halted the endpoint and sent an > error status on the control pipe, causing the host to abort the command > before trying to use the bulk pipe). Fortunately at those times the > endpoint queues should be either empty or halted. As I implied. :) So there's no reason normal code would _ever_ issue (on host side) or receive (on peripheral side) a CLEAR_HALT with non-empty queue. > Why doesn't device hardware/firmware simply ignore CLEAR_HALT requests for > endpoints that aren't halted, other than to reset the toggle and send a > valid reply? Most hardware doesn't seem to offer independent control over the data toggle. And since the mass storage protocol is the main user of endpoint halts, case that crop up with alternate uses of the CLEAR_HALT request aren't likely to be noticed in time to change the silicon ... or to be viewed as important enough to change it. Regardless of how one interprets the USB spec, "best practice" will avoid having the host change endpoint HALT features except in the single case of the peripheral setting it, then the host (later) clearing it. > [ Re the problem Pete saw: ] > > The main issue was that error recovery had succeeded but the > error handler didn't realize it. It thought the CD-ROM's "Not ready yet" > messages (spinning up the disc, presumably) indicated failure. OK, that's more clear now. - Dave ------------------------------------------------------- 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
