Hi, On Fri, Apr 01, 2011 at 10:51:21PM -0400, Alan Stern wrote: > > On Fri, Apr 01, 2011 at 06:34:42PM +0300, Felipe Balbi wrote: > > > > The correct approach is to align on the larger of the block size and > > > > the maxpacket size (provided one is a multiple of the other, which > > > > isn't always true with wireless USB!). In theory short transfers > > > > How about this instead ? (completely untested, compile tested only) > > No good. Changing the block size isn't so easy. In addition to all > the 512 and 511 values, you have to change a number of places that do > << 9 or >> 9. I see, like I said. Completely untested. > > I still need to be sure if I'm using the correct endpoints on all > > locations, I'm a bit confused about do_read_capacity() and do_verify() > > will spend more time with this approach if you think it's good enough. > > At least we won't be lying to host saying block size is 512 but aligning > > on 1024 bytes in SuperSpeed. What do you think ? > > 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 ? 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 ? -- 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
