On Wed, 15 Jun 2005, Aric D. Blumer wrote:
> Hello,
>
> I hope I'm using the correct email address to contact you.
Yes. It's appropriate to CC: these things to the linux-usb-devel mailing
list too, and I've taken the liberty of doing so.
> I'm having a
> bit of trouble with the file_storage gadget, and I want to bounce off
> you what appears to be an error to me.
>
> In the finish_reply() function, there is this section of code:
>
> /* For Bulk-only, if we're allowed to stall then send the
> * short packet and halt the bulk-in endpoint. If we can't
> * stall, pad out the remaining data with 0's. */
> else {
> if (mod_data.can_stall) {
> bh->inreq->zero = 1;
> start_transfer(fsg, fsg->bulk_in, bh->inreq,
> &bh->inreq_busy, &bh->state);
> fsg->next_buffhd_to_fill = bh->next;
> rc = halt_bulk_in_endpoint(fsg);
> } else
> rc = pad_with_zeros(fsg);
> }
>
> This is the section of code that is causing me problems. It is sending
> the last part of data to the host then issuing a halt command. With a
> Linux 2.6.11 host, this results in USB_BULK_RESET_REQUESTs from the
> host, and data being read does not make it to the host. This is the USB
> sequence from this code:
>
> Bulk IN -> Data 0/1 -> Stall
>
> In looking at the USB spec version 2.0, bulk-in cannot take this state
> path. On page 221, it reads, "When the host is ready to receive bulk
> data, it issues an IN token. The function endpoint responds by returning
> either a data packet or, should it be unable to return data, a NAK or
> STALL handshake." So the data packet and stall are mutually exclusive.
The actual sequence of packets depends not on the host but on the USB
hardware controller driver for the gadget. Your diagram indicates that
the host sends an IN packet, then the gadget sends a DATA packet, and then
the gadget sends a STALL packet. That certainly is not a legal sequence;
the device is not allowed to send STALL (or anything else) without the
host soliciting a response. Are you certain there isn't another IN packet
between the DATA and the STALL?
The intended behavior is that the buffer, including its final short
packet, will be sent to the host. Following that, in response to the next
IN packet the device should send a STALL. If the device doesn't behave
this way, the fault lies in the controller driver and not in
file_storage.c. You didn't mention which controller driver you are using;
which one is it?
Incidentally, this issue (halting a bulk endpoint that has data pending)
has proven to be very difficult for device controllers to get right.
That's why file_storage.c has a special routine, halt_bulk_in_endpoint(),
for just this purpose.
> I removed the "rc = halt_bulk_in_endpoint(fsg);" call, and it now works.
> (And of course, it works when I modprobe with stall=0.) I'm no USB
> expert, but this does look like an error to me. What are your thoughts?
Unfortunately the stall is not optional; it's mandatory according to the
Mass Storage Bulk-Only specification. So it can't just be removed. The
correct fix is to repair the controller driver.
Alan Stern
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
