Sorry the GUI here sent that last reply from me prematurely. Continuing now from where I left off:
> > > 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) ... Yes on paper the 1999 Sep 31 BOT 1.0 (aka BBB = command/ data/ status by bulk/ bulk/ bulk) allows stall-free device, provided such a device reports accurate dCSWDataResidue. > > > this also makes it more reliable. Myself I've never seen a bus trace of a stall-free BBB device shipped in volume - has anyone? Padding with anything but determinate zeroes by definition assaults the host with noise, dunno if we ever will provoke an unpleasant response that way. Mostly I've seen people deprecate stall-free BBB by arguing that the host may not have actually allotted all of the dCBWDataTransferLength, nor all of what the bCWBCB allows, but rather only the count of bytes that most actual devices agree to copy in. In that case, the padding added by stall-free BBB writes over unallotted space in the space, with naturally indeterminate results. > > 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 -- Yes, as above. > > and anyway the controller driver _has_ to be able to halt endpoints safely > > to be more widely useful. This I accept on authority, personally I'm an mass-storage-class usb person, not so much a core usb person. Pat LaVarre P.S. Personally I'm delighted to see people experimenting with stall-free BBB. I feel I personally argued stall-free BBB into existence in 1998. But I think then I only had in mind situations where the same vendor manufactures both host and device. When connecting to a host at random, I imagine often we will actually discover that the apps authoring cdb's do not always carefully allot what they claim. I have actually seen the bug of allotting less than the bCWBCB and/or dCBWDataTransferLength supposedly allows in apps when experimenting with drivers that actually choose to add the padding theoretically allowed. Double-buffering in the kernel can make such apps work anyhow, but naive double-buffering injures throughput by definition. ------------------------------------------------------- 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
