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 <[email protected]>
---
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
On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello <[email protected]> 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 <[email protected]>
> ---
> 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
Hi Steve,
On 09/03/16 22:43, Steve Calfee wrote:
> On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello <[email protected]> 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 <[email protected]>
>> ---
>> 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
Steve Calfee wrote:
> On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello <[email protected]> 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
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 <[email protected]>
Acked-by: Michal Nazarewicz <[email protected]>
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»
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 <[email protected]>
>
> Acked-by: Michal Nazarewicz <[email protected]>
>
> 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
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
Michal Nazarewicz <[email protected]> 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 <[email protected]>
>
> Acked-by: Michal Nazarewicz <[email protected]>
>
> 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
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»
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
Hi,
Felipe Ferreri Tonello <[email protected]> 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
Hi Balbi,
On 01/04/16 11:22, Felipe Balbi wrote:
>
> Hi,
>
> Felipe Ferreri Tonello <[email protected]> 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
Hi,
Felipe Ferreri Tonello <[email protected]> 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
Hi Balbi,
On 04/04/16 11:46, Felipe Balbi wrote:
>
> Hi,
>
> Felipe Ferreri Tonello <[email protected]> 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