On Mon, 4 Apr 2011, Felipe Balbi wrote: > Hi, > > On Mon, Apr 04, 2011 at 10:38:54AM -0400, Alan Stern wrote: > > > > As for short transfers... In theory, if everything is working > > > > correctly, the Bulk-Only Transport never has short bulk-OUT transfers. > > > > (Of course, if something goes wrong then one could occur.) Still, I > > > > don't see why you're so anxious to avoid them. Short transfers are a > > > > fact of life, explicitly allowed for in the USB spec. Why worry about > > > > them? > > > > > > HW requests OUT transfers to be aligned on wMaxPacketSize. > > > > That doesn't seem to be related to my question: Why are you worrying > > about short transfers? > > not worrying about short transfers per se, I just want gadget driver to > pass me request->length (for RX/OUT only) which is divisable by > wMaxPacketSize, so I don't have to keep on guessing what size should I > use. You don't have to guess. Always use request->length. :-) > See, if gadget passes me request->length which isn't divisible by > wMaxPacketSize I have two options: > > a. round-down: > That would mean I would need another buffer to receive the > remaining request->length % ep->maxpacket and later memcpy() > those remaining bytes to request->buf > > b. round-up: > Simply can't, I don't know if gadget driver has allocated more > than request->length. You left out the correct, third choice: Don't round; use the value you were asked to use. > > No, you still don't understand. If a particular bulk-OUT request is > > not the last one in a transfer then its length _must_ be a multiple of > > wMaxPacketSize. Otherwise the request will get an EOVERFLOW error. > > > > For example, let's say the host is going to send 2048 bytes, and the > > gadget decides to submit two bulk-OUT requests to receive the data: one > > for 1536 bytes and one for 512 bytes. The first 1024-byte packet will > > be received okay, but the second 1024-byte packet will overflow the 512 > > bytes remaining in the first request's transfer buffer. > > and that's what I'm trying to get fixed, but you say I shouldn't worry > about g_file_storage assuming packet size to be 512 :-) > > Which sounds weird as we round-up request->length when we're queueing > CBW request. As I said earlier, that has been changed. Anyway, I may understand what you're trying to accomplish. I'll send a patch (for g_file_storage only) for you to test in a little while. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
