Re: usb: gadget: f_fs: O_NONBLOCK waits MAX_SCHEDULE_TIMEOUT

["Baxter, Jim" <jim_baxter@mentor.com>]

>>>>>
>>>>> FunctionFS is very specific, because read/write operations are
>>>>> directly translated into USB requests, which are asynchronous, so
>>>>> you cannot use O_NONBLOCK.
>>>>>
>>>>> If you need non-blocking API you can use Asynchronous I/O (AIO). You
>>>>> can find some examples in kernel sources (tools/usb/ffs-aio-example/).
>>>>>
>>>>> Br,
>>>>> Robert Baldyga
>>>>>
>>>>
>>>> Thank you, that sounds like the best approach.
>>>> In this case I think perhaps the long wait without any data is an
>>>> problem with the imx6 Chipidea USB controller.
>>>
>>> What's the possible problem?
>>
>> Sorry for the delay in replying, I have been getting some more details with a
>> USB Analyser.
>>
>> The scenario is that the NCM  device is enumerating so we see the messages to:
>>
>> SetAddress (1)
>> GetDescriptor (Device)
>> GetDescriptor (StringN)
>> GetDescriptor (Configuration)
>> SetConfiguration (1)
>> GetDescriptor (String iInterface)
>> GetDescriptor (String iInterface)
>>
>> At this point the NCM host sends Writes to the F_FS EP0 but for some reason
>> the host device does not respond and only issues SOF packets for hours. This
>> happens occasionally and is fixed by turning the device off and on again.
>>
>>
> 
> We may find this 'some reason', is it device error or host error?
> 
> Do you have below patch in your code:
> 
> commit 953c66469735aed8d2ada639a72b150f01dae605
> Author: Abbas Raza <Abbas_Raza@mentor.com>
> Date:   Thu Jul 17 19:34:31 2014 +0800
> 
>     usb: chipidea: udc: Disable auto ZLP generation on ep0
>     
>     There are 2 methods for ZLP (zero-length packet) generation:
>     1) In software
>     2) Automatic generation by device controller
>     
>     1) is implemented in UDC driver and it attaches ZLP to IN packet if
>        descriptor->size < wLength
>     2) can be enabled/disabled by setting ZLT bit in the QH
>     
> Peter

Yes I have that patch, could that be a problem?

Jim

> 
>> Unless I am mistaken from a NCM gadget point of view the attached device is
>> working correctly and there is no way to know it has failed, is that correct?
>>
>>>
>>>>
>>>> I guess it should suspend and drop the connections if there is no
>>>> traffic for more than 10ms?
>>>>
>>>
>>> If the Device side NAK host's IN/OUT token continually, the pipe will
>>> not be stopped, the host will send token continually until the
>>> application cancel this request.
>>>