[PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Felipe F. Tonello]

buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
devices.

That caused the OUT endpoint to freeze if the host send any data packet of
length greater than 256 bytes.

This is an example dump of what happended on that enpoint:
HOST:   [DATA][Length=260][...]
DEVICE: [NAK]
HOST:   [PING]
DEVICE: [NAK]
HOST:   [PING]
DEVICE: [NAK]
...
HOST:   [PING]
DEVICE: [NAK]

This patch fixes this problem by setting the minimum usb_request's buffer size
for the OUT endpoint as its wMaxPacketSize.

Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
---
 drivers/usb/gadget/function/f_midi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_midi.c b/drivers/usb/gadget/function/f_midi.c
index 8475e3dc82d4..826ba641f29d 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
 	/* allocate a bunch of read buffers and queue them all at once. */
 	for (i = 0; i < midi->qlen && err == 0; i++) {
 		struct usb_request *req =
-			midi_alloc_ep_req(midi->out_ep, midi->buflen);
+			midi_alloc_ep_req(midi->out_ep,
+				max_t(unsigned, midi->buflen,
+					bulk_out_desc.wMaxPacketSize));
 		if (req == NULL)
 			return -ENOMEM;
 
-- 
2.7.2

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Steve Calfee]

On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello <eu@felipetonello.com> wrote:
> buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
> devices.
>
> That caused the OUT endpoint to freeze if the host send any data packet of
> length greater than 256 bytes.
>
> This is an example dump of what happended on that enpoint:
> HOST:   [DATA][Length=260][...]
> DEVICE: [NAK]
> HOST:   [PING]
> DEVICE: [NAK]
> HOST:   [PING]
> DEVICE: [NAK]
> ...
> HOST:   [PING]
> DEVICE: [NAK]
>
> This patch fixes this problem by setting the minimum usb_request's buffer size
> for the OUT endpoint as its wMaxPacketSize.
>
> Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
> ---
>  drivers/usb/gadget/function/f_midi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/function/f_midi.c b/drivers/usb/gadget/function/f_midi.c
> index 8475e3dc82d4..826ba641f29d 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
>         /* allocate a bunch of read buffers and queue them all at once. */
>         for (i = 0; i < midi->qlen && err == 0; i++) {
>                 struct usb_request *req =
> -                       midi_alloc_ep_req(midi->out_ep, midi->buflen);
> +                       midi_alloc_ep_req(midi->out_ep,
> +                               max_t(unsigned, midi->buflen,
> +                                       bulk_out_desc.wMaxPacketSize));
>                 if (req == NULL)
>                         return -ENOMEM;
>
Won't you get a buffer overrun if midi->buflen is less than wMaxPacketSize?

Regards, Steve

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Felipe Ferreri Tonello]

[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]

Hi Steve,

On 09/03/16 22:43, Steve Calfee wrote:
> On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello <eu@felipetonello.com> wrote:
>> buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
>> devices.
>>
>> That caused the OUT endpoint to freeze if the host send any data packet of
>> length greater than 256 bytes.
>>
>> This is an example dump of what happended on that enpoint:
>> HOST:   [DATA][Length=260][...]
>> DEVICE: [NAK]
>> HOST:   [PING]
>> DEVICE: [NAK]
>> HOST:   [PING]
>> DEVICE: [NAK]
>> ...
>> HOST:   [PING]
>> DEVICE: [NAK]
>>
>> This patch fixes this problem by setting the minimum usb_request's buffer size
>> for the OUT endpoint as its wMaxPacketSize.
>>
>> Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
>> ---
>>  drivers/usb/gadget/function/f_midi.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c b/drivers/usb/gadget/function/f_midi.c
>> index 8475e3dc82d4..826ba641f29d 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
>>         /* allocate a bunch of read buffers and queue them all at once. */
>>         for (i = 0; i < midi->qlen && err == 0; i++) {
>>                 struct usb_request *req =
>> -                       midi_alloc_ep_req(midi->out_ep, midi->buflen);
>> +                       midi_alloc_ep_req(midi->out_ep,
>> +                               max_t(unsigned, midi->buflen,
>> +                                       bulk_out_desc.wMaxPacketSize));
>>                 if (req == NULL)
>>                         return -ENOMEM;
>>
> Won't you get a buffer overrun if midi->buflen is less than wMaxPacketSize?
> 

No, because of the *max_t(unsigned, midi->buflen,
bulk_out_desc.wMaxPacketSize)*.

Maybe that's not the most clear indentation but I had to break it in
order to avoid passing 80 columns.

-- 
Felipe

[-- Attachment #2: 0x92698E6A.asc --]
[-- Type: application/pgp-keys, Size: 7310 bytes --]

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Clemens Ladisch]

Steve Calfee wrote:
> On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello <eu@felipetonello.com> wrote:
>> [...]
>> This patch fixes this problem by setting the minimum usb_request's buffer size
>> for the OUT endpoint as its wMaxPacketSize.
>>
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
>>                 struct usb_request *req =
>> -                       midi_alloc_ep_req(midi->out_ep, midi->buflen);
>> +                       midi_alloc_ep_req(midi->out_ep,
>> +                               max_t(unsigned, midi->buflen,
>> +                                       bulk_out_desc.wMaxPacketSize));
>
> Won't you get a buffer overrun if midi->buflen is less than wMaxPacketSize?

No.  f_midi_handle_out_data() uses only the request buffer.


Regards,
Clemens

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Michal Nazarewicz]

On Wed, Mar 09 2016, Felipe F. Tonello wrote:
> buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
> devices.
>
> That caused the OUT endpoint to freeze if the host send any data packet of
> length greater than 256 bytes.
>
> This is an example dump of what happended on that enpoint:
> HOST:   [DATA][Length=260][...]
> DEVICE: [NAK]
> HOST:   [PING]
> DEVICE: [NAK]
> HOST:   [PING]
> DEVICE: [NAK]
> ...
> HOST:   [PING]
> DEVICE: [NAK]
>
> This patch fixes this problem by setting the minimum usb_request's buffer size
> for the OUT endpoint as its wMaxPacketSize.
>
> Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>

Acked-by: Michal Nazarewicz <mina86@mina86.com>

But see comment below:

> ---
>  drivers/usb/gadget/function/f_midi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/function/f_midi.c b/drivers/usb/gadget/function/f_midi.c
> index 8475e3dc82d4..826ba641f29d 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
>  	/* allocate a bunch of read buffers and queue them all at once. */
>  	for (i = 0; i < midi->qlen && err == 0; i++) {
>  		struct usb_request *req =
> -			midi_alloc_ep_req(midi->out_ep, midi->buflen);
> +			midi_alloc_ep_req(midi->out_ep,
> +				max_t(unsigned, midi->buflen,
> +					bulk_out_desc.wMaxPacketSize));

Or, just:

+			midi_alloc_ep_req(midi->out_ep,
+					  bulk_out_desc.wMaxPacketSize);

Packet cannot be greater than wMaxPacketSize so there is no need to
allocate more (if buflen > wMaxPacketSize).

>  		if (req == NULL)
>  			return -ENOMEM;
>  

I’m also wondering whether it would be beneficial to get rid of buflen
all together and use wMaxPacketSie for in endpoints as well?  Is that
feasible?

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Felipe Ferreri Tonello]

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

Hi Michal,

On 11/03/16 23:07, Michal Nazarewicz wrote:
> On Wed, Mar 09 2016, Felipe F. Tonello wrote:
>> buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
>> devices.
>>
>> That caused the OUT endpoint to freeze if the host send any data packet of
>> length greater than 256 bytes.
>>
>> This is an example dump of what happended on that enpoint:
>> HOST:   [DATA][Length=260][...]
>> DEVICE: [NAK]
>> HOST:   [PING]
>> DEVICE: [NAK]
>> HOST:   [PING]
>> DEVICE: [NAK]
>> ...
>> HOST:   [PING]
>> DEVICE: [NAK]
>>
>> This patch fixes this problem by setting the minimum usb_request's buffer size
>> for the OUT endpoint as its wMaxPacketSize.
>>
>> Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
> 
> Acked-by: Michal Nazarewicz <mina86@mina86.com>
> 
> But see comment below:
> 
>> ---
>>  drivers/usb/gadget/function/f_midi.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c b/drivers/usb/gadget/function/f_midi.c
>> index 8475e3dc82d4..826ba641f29d 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
>>  	/* allocate a bunch of read buffers and queue them all at once. */
>>  	for (i = 0; i < midi->qlen && err == 0; i++) {
>>  		struct usb_request *req =
>> -			midi_alloc_ep_req(midi->out_ep, midi->buflen);
>> +			midi_alloc_ep_req(midi->out_ep,
>> +				max_t(unsigned, midi->buflen,
>> +					bulk_out_desc.wMaxPacketSize));
> 
> Or, just:
> 
> +			midi_alloc_ep_req(midi->out_ep,
> +					  bulk_out_desc.wMaxPacketSize);
> 
> Packet cannot be greater than wMaxPacketSize so there is no need to
> allocate more (if buflen > wMaxPacketSize).

I didn't know that was a constraint. If so, I agree with you.

> 
>>  		if (req == NULL)
>>  			return -ENOMEM;
>>  
> 
> I’m also wondering whether it would be beneficial to get rid of buflen
> all together and use wMaxPacketSie for in endpoints as well?  Is that
> feasible?

Yes, we could just remove the buflen parameter.

The only scenario where I can see buflen been "useful" is if the user
wants to have a smaller buffer size for the OUT endpoint. Should we
support this case or not?

I can rework this patch for any case we agree on.

-- 
Felipe

[-- Attachment #2: 0x92698E6A.asc --]
[-- Type: application/pgp-keys, Size: 7195 bytes --]

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
> On 11/03/16 23:07, Michal Nazarewicz wrote:
>> I’m also wondering whether it would be beneficial to get rid of buflen
>> all together and use wMaxPacketSie for in endpoints as well?  Is that
>> feasible?
>
> Yes, we could just remove the buflen parameter.
>
> The only scenario where I can see buflen been "useful" is if the user
> wants to have a smaller buffer size for the OUT endpoint. Should we
> support this case or not?

Splitting data into multiple packets would not make sense from
a performance perspective.  The only possible reason would be to work
around a (theoretical) bug in some host software that does not handle
larger buffers, but there aren't that many host implementations, and I
am not aware of any with such a bug.


Regards,
Clemens

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]

Michal Nazarewicz <mina86@mina86.com> writes:
> [ text/plain ]
> On Wed, Mar 09 2016, Felipe F. Tonello wrote:
>> buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
>> devices.
>>
>> That caused the OUT endpoint to freeze if the host send any data packet of
>> length greater than 256 bytes.
>>
>> This is an example dump of what happended on that enpoint:
>> HOST:   [DATA][Length=260][...]
>> DEVICE: [NAK]
>> HOST:   [PING]
>> DEVICE: [NAK]
>> HOST:   [PING]
>> DEVICE: [NAK]
>> ...
>> HOST:   [PING]
>> DEVICE: [NAK]
>>
>> This patch fixes this problem by setting the minimum usb_request's buffer size
>> for the OUT endpoint as its wMaxPacketSize.
>>
>> Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
>
> Acked-by: Michal Nazarewicz <mina86@mina86.com>
>
> But see comment below:
>
>> ---
>>  drivers/usb/gadget/function/f_midi.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c b/drivers/usb/gadget/function/f_midi.c
>> index 8475e3dc82d4..826ba641f29d 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
>>  	/* allocate a bunch of read buffers and queue them all at once. */
>>  	for (i = 0; i < midi->qlen && err == 0; i++) {
>>  		struct usb_request *req =
>> -			midi_alloc_ep_req(midi->out_ep, midi->buflen);
>> +			midi_alloc_ep_req(midi->out_ep,
>> +				max_t(unsigned, midi->buflen,
>> +					bulk_out_desc.wMaxPacketSize));
>
> Or, just:
>
> +			midi_alloc_ep_req(midi->out_ep,
> +					  bulk_out_desc.wMaxPacketSize);
>
> Packet cannot be greater than wMaxPacketSize so there is no need to
> allocate more (if buflen > wMaxPacketSize).

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.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Michal Nazarewicz]

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).

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Felipe Ferreri Tonello]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

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)

-- 
Felipe

[-- Attachment #2: 0x92698E6A.asc --]
[-- Type: application/pgp-keys, Size: 7195 bytes --]

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]


Hi,

Felipe Ferreri Tonello <eu@felipetonello.com> 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.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Felipe Ferreri Tonello]

[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]

Hi Balbi,

On 01/04/16 11:22, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Ferreri Tonello <eu@felipetonello.com> 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 #2: 0x92698E6A.asc --]
[-- Type: application/pgp-keys, Size: 7195 bytes --]

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]


Hi,

Felipe Ferreri Tonello <eu@felipetonello.com> writes:
>>> 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?

also applicable

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Felipe Ferreri Tonello]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

Hi Balbi,

On 04/04/16 11:46, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Ferreri Tonello <eu@felipetonello.com> writes:
>>>> 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?
> 
> also applicable
> 

Ok, so I will make few tests here and resend a v3 probably with buflen
still.

-- 
Felipe

[-- Attachment #2: 0x92698E6A.asc --]
[-- Type: application/pgp-keys, Size: 7195 bytes --]