Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753821AbbFAQZg (ORCPT ); Mon, 1 Jun 2015 12:25:36 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:44696 "EHLO relay1.mentorg.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751910AbbFAQZ0 (ORCPT ); Mon, 1 Jun 2015 12:25:26 -0400 Message-ID: <556C8773.9070702@mentor.com> Date: Mon, 1 Jun 2015 17:25:23 +0100 From: "Baxter, Jim" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Peter Chen CC: Robert Baldyga , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" , "Zapolskiy, Vladimir" , "balbi@ti.com" Subject: Re: usb: gadget: f_fs: O_NONBLOCK waits MAX_SCHEDULE_TIMEOUT References: <551AED33.2040206@mentor.com> <551BA70B.1090706@samsung.com> <551C2AE1.9000608@mentor.com> <20150402002348.GA10964@shlinux2> <555F0F29.1070108@mentor.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [137.202.0.76] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2661 Lines: 80 >>>>> >>>>> 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 > 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. >>> -- 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/