Hi, On Fri, Apr 01, 2011 at 10:59:18AM -0400, Alan Stern wrote: > On Fri, 1 Apr 2011, Felipe Balbi wrote: > > > On Fri, Apr 01, 2011 at 01:36:00PM +0200, Michal Nazarewicz wrote: > > > On Fri, 01 Apr 2011 12:19:59 +0200, Felipe Balbi <balbi@xxxxxx> wrote: > > > >we shouldn't assume that value because on SuperSpeed, we have > > > >1024 as wMaxPacketSize. > > > > > > The more I look at the code, the more I wonder whether this 511 > > > constant is a consequence of wMaxPacketSize being 512 or mass > > > storage using 512-byte blocks when reading/writing data from/to > > > backing file. > > > > My understanding is that the code is trying to align the size of > > transfers to wMaxPacketSize, see that it also sets short_not_ok flag on > > the same path. > > > > Alan, what do you say ? > > The situation is complicated. Michal is right that the 511 value > refers to the block size, not the maxpacket size. However the logic in Ok, so I mis-understood the code. Sorry for that :-p > this routine assumes that the maxpacket size divides the block size, > and with SuperSpeed that won't be true unless the block size is > increased to 1024. Fixing the assumption will require more than > changing this one line. Ok, thanks for the info. I'll spend some time with it during next week. What do you suggest in this case ? I mean, we shouldn't be doing short transfers with this gadget driver, right ? And if block size is always 512, how can we transfer one block without having a short transfer ? Should we, then make the block size == wMaxPacketSize and keep aligning on a block boundary ? -- 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
