> > The problem is that the hardware is (again) trying to be too clever. I > > set a bit in a register to stall an endpoint. The hardware also has an > > internal stall bit for each endpoint (not accessible to software). When > > the host attempts a transaction on an endpoint the hardware checks the > > internal stall bit and if this is set it sends a stall, if the internal > > bit is not set it checks the software settable bit and if this is set it > > latches the internal bit and sends a stall.
This sounds familiar. In effect, setting the internal stall bit queues a stall to the host. > > Resetting the software stall bit does not affect the latched bit, the > > latched bit can only be cleared by a Clear Feature command from the > > host. But the Clear Feature is processed by the hardware and the > > software is not informed. Does the hardware merely not interrupt the software, or does the software have no way to sample the internal stall bit to discover if the stall has or has not occurred? How does Get Feature work? > > If I leave the software stall bit set there will be another stall on > > the next transaction so I need to clear the stall bit. > > This sounds very strange indeed. It implies that there's no reliable way > for the UDC driver to halt an endpoint. Aye. > > I ... starting a timer to clear the stall bit sometime after I set it. > > I wouldn't expect there to be any good way of making that work. Me neither. > > I've also added an option to the mass storage gadget to pad out short > > replies rather than sending the short reply and stalling (this seems > > to be a valid alternative according to the mass storage spec) and > > this also makes it more reliable. > > It's impossible to implement all the commands. More realistic is your > other option, switching the gadget to use the no-stall option in the > Bulk-only spec. > > I've been having a discussion about this off-list with Pat LaVarre and > David Brownell. Our general conclusion has been that although the > no-stall option is better for the controller driver (since it doesn't have > to worry about halting endpoints) and might lead to somewhat increased > throughput, nevertheless using stalls is probably more interoperable -- > and anyway the controller driver _has_ to be able to halt endpoints safely > to be more widely useful. > > I also considered the possibility of adding a "no-stall" option to the > storage gadget, but it seemed like such an obscure sort of thing that > nobody would ever want to have to worry about it. > > Are you quite sure there's no way to halt endpoints sensibly on your UDC? > > Alan Stern > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
