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

[Felipe Ferreri Tonello]

Hi Balbi,

On 04/04/16 11:46, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Ferreri Tonello  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


0x92698E6A.asc
Description: application/pgp-keys

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

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  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


signature.asc
Description: PGP signature

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

[Felipe Ferreri Tonello]

Hi Balbi,

On 01/04/16 11:22, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Ferreri Tonello  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


0x92698E6A.asc
Description: application/pgp-keys

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

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  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


signature.asc
Description: PGP signature

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

[Felipe Ferreri Tonello]

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


0x92698E6A.asc
Description: application/pgp-keys

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

[Felipe Balbi]

Michal Nazarewicz  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 
>
> Acked-by: Michal Nazarewicz 
>
> 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


signature.asc
Description: PGP signature

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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Felipe Ferreri Tonello]

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 
> 
> Acked-by: Michal Nazarewicz 
> 
> 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


0x92698E6A.asc
Description: application/pgp-keys

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 

Acked-by: Michal Nazarewicz 

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»
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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  
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Steve Calfee]

On Thu, Mar 10, 2016 at 1:23 AM, Felipe Ferreri Tonello
 wrote:

>>> --- 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.
>
Yes, I understood that code. It is a little confusing that gadgets use
OUT endpoints to receive data.

I think we are talking about different buffers. I meant that if you
ever received data into your enlarged ep buffer, will you not copy it
into your midi buffer? If the code checks, I guess you will truncate
the received data? If not, it could be a midi buffer overrun.

Regards, Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Felipe Ferreri Tonello]

Hi Steve,

On 09/03/16 22:43, Steve Calfee wrote:
> On Wed, Mar 9, 2016 at 11:39 AM, 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 
>> ---
>>  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


0x92698E6A.asc
Description: application/pgp-keys

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  
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 
> ---
>  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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html