Alan Stern wrote:
David:
This question is somewhat theoretical; I don't expect it to come up. But
I'm curious.
Do the slave controller drivers maintain message boundaries for bulk-out
endpoints, even if the gadget's request size doesn't match the host's
packet size?
Yes, modulo overflows and hardware mis-designs.
Here's an example to clarify the question. Suppose the host sends a
100-byte message, divided into a 64-byte (maxlen) packet X and a short
36-byte packet Y. Suppose the gadget driver queues a request A for 36
bytes, a request B for 64 bytes, and a request C for 64 bytes.
That suggests the two drivers disagree on the data they're exchanging.
Ideally, the gadget driver would queue one request for 100 bytes rather
than issuing lots of packet-size requests.
Presumably A will be returned with the first 36 bytes from X. At this
point a host controller would report a babble error, since the actual
packet length is the expected length. Does the gadget API include an
equivalent notion? Or does the remainder of X stay in the FIFO, to be
returned in B?
The device controller driver should behave the same way as the host
controller driver does for the same case: report a babble (-EOVERFLOW)
and discard the rest of that packet.
Of course the gadget driver can issue reads that are always at least
maxpacket in size, and then figure out what to do with the extra data.
Most protocols I've seen won't want to bother with that, since they're
defined in terms of packets, not bytes.
There do seem to be controllers that don't have a way to respect
packet boundaries. It's pretty hopeless to implement typical
protocols on that hardware, since they're defined in terms of
packet boundaries -- notably using short packets (including zlps)
to terminate transfers.
If yes, then B returns with the last 28 bytes of X plus the 36 bytes of Y.
Since Y is short, it marks a message boundary. Does the controller then
return C containing 0 bytes to mark the end of the message? Or does C
wait until the host sends more data, so the gadget driver is unaware of
the message boundary?
Yes to your first question, no to the second; so B will get 36 bytes
and C will not complete until the host sends a third packet.
Here's another example. Suppose the host does the same as before, but now
the gadget driver queues A for 40 bytes and B for 64. Then A gets the
first 40 bytes of X and B gets the last 24 plus the 36 bytes of Y. Since
Y marks a message boundary, does B then return as a short request with
only 60 bytes? Or does it wait until the host sends more data?
Same thing again. A returns 40 bytes with -EOVERFLOW, discarding the
extra data. B returns 36 bytes with normal status.
USB talks in terms of packets, and that's how both host and device
side APIs talk. If you want to accomodate the two sides disagreeing
on how much data is sent, then each side needs to avoid issuing short
reads ... and have some strategy for coping with that disagreement.
- Dave
Alan Stern
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
