On Fri, 1 Apr 2011, Felipe Balbi wrote:
> Hi,
>
> On Fri, Apr 01, 2011 at 11:29:20AM -0400, Alan Stern wrote:
> > > 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 ?
> >
> > "Short" means "shorter than expected", not "shorter than the maxpacket
> > size".
> >
> > > Should we, then make the block size == wMaxPacketSize and keep aligning
> > > on a block boundary ?
> >
> > 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
>
> I like this approach. Will play with it next week :-)
>
> Just to be sure I understood, you mean something like:
>
> if (!(ep->maxpacket % block_size))
> align = max(ep->maxpacket, block_size);
> else
> align = block_size;
>
> amount &= ~(align - 1);
>
> ???
Actually I meant something like this (in fsg_bind):
a = max(ep->maxpacket, block_size);
b = min(ep->maxpacket, block_size);
if (a % b != 0) {
print an error message
return -EIO;
}
and then later on:
align = max(ep->maxpacket, block_size);
amount &= ~(align - 1);
This can be simplified if you realize that block_size is currently
fixed at 512. Also we know that except for wireless USB, the
maxpacket value must be 64, 512, or 1024 -- which means the first
test is unnecessary.
> > shouldn't occur, but it doesn't matter much if they do, provided they
> > are a multiple of the block size.
>
> What about controllers which can't handle Short on RX ?
Such controllers are broken and can't be used by g_file_storage.
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
