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.
Minor clarification: I've left the "flash-BBB" vs "no-stall BBB" interop tradeoffs to you experts ... I'm neutral! :)
My concern here to cleanup the usb_ep_set_halt() semantics so it was usable for a "real driver", one that didn't need to care about the hardware underneath it. I think we're probably as close as we can get to that state now (BK-current), but we still have things to learn about how SuperH behaves (or doesn't).
If SuperH really can't implement endpoint halts in a usable way (except for ep0), then the options would seem to be (a) kick in the "no-stall" protocol option, at least when SuperH is in use, or (b) just say SuperH can't support FSG. The former sounds a lot better to me...
That's just my two centipedes...
- Dave
------------------------------------------------------- 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
