Hi Balbi, On 01/04/16 11:22, Felipe Balbi wrote: > > Hi, > > Felipe Ferreri Tonello <eu@xxxxxxxxxxxxxxxxx> writes: >> Hi Balbi and Mina, >> >> On 30/03/16 13:33, Michal Nazarewicz wrote: >>> On Wed, Mar 30 2016, Felipe Balbi wrote: >>>> a USB packet, right. that's correct. But a struct usb_request can >>>> point to whatever size buffer it wants and UDC is required to split >>>> that into wMaxPacketSize transfers. >>> >>> D’oh. Of course. Disregard all my comments on the patch (except for >>> Ack). >>> >> >> I didn't really get it. Does that mean that if buflen is multiple of >> wMaxPacketSize, the UDC driver should fit as many [DATA] packets into >> one usb_request and call complete() or it will always call complete() on >> each [DATA] packet, thus not requiring buflen at all? >> >> Does that mean that we can still use buflen and this patch is still >> valid? (besides the endianess issue that was addressed on v2) > > if you have e.g. 2048 bytes of data to transfer and wMaxPacketSize is > e.g. 256 bytes, the UDC controller is required to do whatever it needs > to do to transfer 2048 bytes (or less if there's a short packet). > > You don't need to break these 2048 bytes into several requests yourself, > the UDC is required to do that for the gadget. Right, what about OUT endpoints? So that means that buflen is still usable, at least on IN endpoints. -- Felipe
Attachment:
0x92698E6A.asc
Description: application/pgp-keys
