On 11/25/2014 08:39 PM, Paul Zimmerman wrote:
>> diff --git a/drivers/usb/gadget/function/f_sourcesink.c
>> b/drivers/usb/gadget/function/f_sourcesink.c
>> index 80be25b32cd7..7d8f0216e1a6 100644
>> --- a/drivers/usb/gadget/function/f_sourcesink.c
>> +++ b/drivers/usb/gadget/function/f_sourcesink.c
>> @@ -161,7 +161,7 @@ static struct usb_endpoint_descriptor fs_int_source_desc
>> = {
>>
>> .bEndpointAddress = USB_DIR_IN,
>> .bmAttributes = USB_ENDPOINT_XFER_INT,
>> - .wMaxPacketSize = cpu_to_le16(64),
>> + .wMaxPacketSize = cpu_to_le16(1024),
>
> This seems strange. You are setting the max packet size in the FS Intr
> endpoint descriptor to a value that is illegal for FS. Won't that cause
> usb_ep_autoconfig() to fail if the UDC only has a FS Intr endpoint?
Funny at it is, tests have shown to work as expected. Only if UDC is FS
only then it won't pass. This could be fixed…
> Maybe you should set wMaxPacketSize to 0 instead? The ep_matches()
> function in epautoconf.c has this code:
> /*
> * If the protocol driver hasn't yet decided on wMaxPacketSize
> * and wants to know the maximum possible, provide the info.
> */
> if (desc->wMaxPacketSize == 0)
> desc->wMaxPacketSize = cpu_to_le16(ep->maxpacket_limit);
>
This means we get most likely the smallest possible endpoint and won't
be able to perform transfers @1024 even if we would have such an
endpoint.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
