Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754769AbbFBDBX (ORCPT ); Mon, 1 Jun 2015 23:01:23 -0400 Received: from mail-bn1bn0107.outbound.protection.outlook.com ([157.56.110.107]:1486 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751539AbbFBDBQ convert rfc822-to-8bit (ORCPT ); Mon, 1 Jun 2015 23:01:16 -0400 From: Peter Chen To: "Baxter, Jim" 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 Thread-Topic: usb: gadget: f_fs: O_NONBLOCK waits MAX_SCHEDULE_TIMEOUT Thread-Index: AQHQa+QM1XzjMiA4I0uYsSeURtZl8503zcKAgACdKYCAAPn8AIBOw8CAgAQazSCAC/PigIAAsWFQ Date: Tue, 2 Jun 2015 03:01:12 +0000 Message-ID: References: <551AED33.2040206@mentor.com> <551BA70B.1090706@samsung.com> <551C2AE1.9000608@mentor.com> <20150402002348.GA10964@shlinux2> <555F0F29.1070108@mentor.com> <556C8773.9070702@mentor.com> In-Reply-To: <556C8773.9070702@mentor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Peter.Chen@freescale.com; x-originating-ip: [192.88.170.35] x-microsoft-exchange-diagnostics: 1;BN3PR0301MB0849;3:MacKts3KVr0OJtIAqSldDDzKeV1Tt5k3c2hfhXjpy3JbwWSk1X/eIx05zdqvwZf4Nm+oCiMceoT+212/fL7C3OBejqw4I3cq2qFOISiHKZidnu6tYpvxPb4oMOfkeZx7K0noMsg/XyaYOTWIQBIuYQ==;10:arVRfVZtKW/xxHttizZ+d13n85dzk4m5+iaIgBu5yVo/1ojexXlotwcNjxiQDhB9wPiOVEG+4V737R7M/sesLomffQWvRoOeONsqPkMh0Xk=;6:P+cV050MYV4sWL7m4WwQ6fm0b6VhgD416/jg+XBYpU6VvZ0pmHETBCb58rozrZql x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB0849; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(5005006)(520003)(3002001);SRVR:BN3PR0301MB0849;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB0849; x-forefront-prvs: 05954A7C45 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(51704005)(189002)(199003)(5890100001)(110136002)(5001830100001)(105586002)(19580405001)(40100003)(19580395003)(92566002)(33656002)(86362001)(76176999)(54356999)(101416001)(50986999)(5001960100002)(189998001)(76576001)(97736004)(81156007)(106356001)(5001860100001)(5002640100001)(2900100001)(2950100001)(4001540100001)(68736005)(102836002)(62966003)(77156002)(77096005)(2656002)(87936001)(74316001)(64706001)(106116001)(66066001)(99286002)(46102003)(122556002)(93886004);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR0301MB0849;H:BN3PR0301MB0849.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2015 03:01:12.9318 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB0849 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2472 Lines: 79 > >>>> > >>>> 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? > No, you need that patch. Get to know which side has problem first. Peter > 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/