On Fri, 16 Jul 2004, Pat LaVarre wrote:

> Ok.  I've found a local copy of usbmassbulk_10.pdf
> 
> There I see:
> 
> 6.7.3.2.b.i.1 says "The device shall either accept a total of 
> dCBWDataTransferLength, or end the transfer prematurely by STALLing the 
> Bulk-Out pipe."
> 
> Is that English not clear?
> 
> I think that English is supposed to mean, the device shall not STALL 
> the OUT pipe after the last ACK of OUT, given a CBW that says Ho.  By 
> "last ACK" of course we mean the ACK of the ((Ho+maxPacket - 1) / 
> maxPacket)'th packet.

The problem we face is that the device's hardware may not be able to set
the endpoint's Halt feature until after the last ACK, even if the firmware
requested the feature be set before the ACK was sent.  (That sort of thing
can happen if the device doesn't use a simple uniprocessor to handle all
its chores.)  It's a race, and in all likelihood the device has no way to
guarantee that things will work out correctly.

Todd, the g_file_storage driver has an option that will cause it to make
the other choice.  If you select the test version of the file-storage
gadget in your kernel's configuration, then you can specify as a module
parameter that it should not stall.  You just say something like:

        modprobe g_file_storage file=... stall=n


> Certainly I agree that a STALL of OUT after the last ACK will appear to 
> the host as a STALL of CBW.  That will look to the host as if the 
> device saw the CBW as not "valid" or not "meaningful", and life will go 
> downhill from there.
> 
> > a flaw in the Bulk-only protocol
> 
> (: Mmmm, show me. :)

Well, maybe not a flaw but a weak point.  The spec offers the device a
seemingly valid choice that actually makes a demand the device may not be
able to satisfy.  It would be better if the spec included some additional
language saying something like this:

        If the device is unable to guarantee that the Bulk-Out pipe
        will STALL before all the data have been transferred, then it
        must accept a total of dCBWDataTransferLength and not STALL
        the pipe.

> Meanwhile I will here now renew my solicitation of volunteers to help 
> write a rationale for that .pdf that would make that .pdf less 
> difficult to read accurately, and I thank you again for including me in 
> this interesting thread.

I volunteer to help.

Alan Stern



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to