From: Peter Chen <Peter.Chen@freescale.com>
To: "Baxter, Jim" <jim_baxter@mentor.com>
CC: Robert Baldyga <r.baldyga@samsung.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "Zapolskiy, Vladimir" <Vladimir_Zapolskiy@mentor.com>,
        "balbi@ti.com" <balbi@ti.com>
Subject: RE: usb: gadget: f_fs: O_NONBLOCK waits MAX_SCHEDULE_TIMEOUT
Thread-Topic: usb: gadget: f_fs: O_NONBLOCK waits MAX_SCHEDULE_TIMEOUT
Thread-Index: AQHQa+QM1XzjMiA4I0uYsSeURtZl8503zcKAgACdKYCAAPn8AIBOw8CAgAQazSA=
Date: Mon, 25 May 2015 01:55:51 +0000
Message-ID: <BN3PR0301MB084914E934D705427A81EE4681CD0@BN3PR0301MB0849.namprd03.prod.outlook.com>
References: <551AED33.2040206@mentor.com> <551BA70B.1090706@samsung.com>
 <551C2AE1.9000608@mentor.com> <20150402002348.GA10964@shlinux2>
 <555F0F29.1070108@mentor.com>
In-Reply-To: <555F0F29.1070108@mentor.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2015 01:55:51.6526
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB0850
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2551
Lines: 76

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

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