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. 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. > > > > IMO, it's best to either use wMaxPacketSize as block size, or use "the > > > > more common value of 2048", to avoid it for a few more USB revisions. > > > > Isn't it bad to have the assumption that block size is 512 no matter > > > > what ? > > > > > > What's bad about it? Virtually all the existing disk-like USB mass > > > storage devices (i.e., pretty much everything except USB CDROM drives) > > > use 512-byte blocks. I bet a lot of BIOSes won't be able to boot from > > > a USB disk/flash drive with a block size other than 512. > > > > I see, then I need to find another way to make this work. > > > > But in this, then my patch in completely unnecessary and there's no need > > to align the transfer on wMaxPacketSize at all. > > 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. -- balbi -- 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
