Hi, On Sun, Apr 03, 2011 at 11:58:33AM -0400, Alan Stern wrote: > > > It's a bad idea. I advise against using a variable block size; keep it > > > set to 512. > > > > In that case, how do we avoid short on SuperSpeed ? OUT transfers will > > have to be aligned on wMaxPacketSize (on the controller level at least), > > so if block size is always 512 how can I make a three block transfer be > > aligned on 1024 ? > > Felipe, you're not using the word "short" correctly. A short packet is > one that's smaller than the maxpacket size, whereas a short transfer is > one that's smaller than the recipient expected. Yes, got that much ;-) > So, in your example, if the device expects to receive 3 * 512 bytes, > and the host sends one packet containing 1024 bytes followed by another > packet containing 512 bytes, it _isn't_ a short transfer -- the device > receives exactly what it expects! True, the last packet is a short > packet, but so what? If that's the case, we need to remove the "short_not_ok" flag from the storage gadget. Looking into include/linux/usb/gadget.h that means short _packets_ are treated as errors: 35 * @short_not_ok: When reading data, makes short packets be 36 * treated as errors (queue stops advancing till cleanup). Either remove the flag, or change its sematics. $ git grep -e short_not_ok drivers/usb/gadget/*storage*.c drivers/usb/gadget/f_mass_storage.c: bh->outreq->short_not_ok = 1; drivers/usb/gadget/f_mass_storage.c: bh->outreq->short_not_ok = 1; drivers/usb/gadget/f_mass_storage.c: bh->outreq->short_not_ok = 1; drivers/usb/gadget/file_storage.c: bh->outreq->short_not_ok = 1; drivers/usb/gadget/file_storage.c: bh->outreq->short_not_ok = 1; drivers/usb/gadget/file_storage.c: bh->outreq->short_not_ok = 1; > Now, are you asking how to avoid short packets or short transfers? Short packets. > There's no way to avoid short packets. If the hardware can't handle > short packets, it is completely broken and there's no sense even trying > to use it. As an example, consider that the CBW packet is 31 bytes and > therefore will be short at any speed. This is good point. > 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. > > 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. -- 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
