Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752095AbbGMRuy (ORCPT ); Mon, 13 Jul 2015 13:50:54 -0400 Received: from smtprelay.synopsys.com ([198.182.60.111]:35250 "EHLO smtprelay.synopsys.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751973AbbGMRuw convert rfc822-to-8bit (ORCPT ); Mon, 13 Jul 2015 13:50:52 -0400 From: John Youn To: "balbi@ti.com" , Subbaraya Sundeep Bhatta CC: John Youn , "gregkh@linuxfoundation.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" Subject: Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails Thread-Topic: [PATCH v2 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails Thread-Index: AQHQk7GIA+Sqgb4cD02xex3whosYqw== Date: Mon, 13 Jul 2015 17:50:49 +0000 Message-ID: <2B3535C5ECE8B5419E3ECBE3007729090175270D38@US01WEMBX2.internal.synopsys.com> References: <1432203408-5482-1-git-send-email-sbhatta@xilinx.com> <1432203408-5482-3-git-send-email-sbhatta@xilinx.com> <20150629214701.GK1019@saruman.tx.rr.com> <20150629214854.GL1019@saruman.tx.rr.com> <2B3535C5ECE8B5419E3ECBE3007729090175264F3B@US01WEMBX2.internal.synopsys.com> <20150702030009.GB29462@saruman.tx.rr.com> <2B3535C5ECE8B5419E3ECBE3007729090175267F20@US01WEMBX2.internal.synopsys.com> <20150707032448.GB13135@saruman.tx.rr.com> <20150711192914.GA24195@saruman.tx.rr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.139.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2900 Lines: 74 On 7/11/2015 12:29 PM, Felipe Balbi wrote: > Hi, > > On Sat, Jul 11, 2015 at 05:17:32PM +0000, Subbaraya Sundeep Bhatta wrote: >>>>>> Hi Felipe, >>>>>> >>>>>> Just an update on this. >>>>>> >>>>>> I'm trying to get this working with our latest IP with dwc3 from >>>>>> your testing/next branch. It fails the usbtest with a problem >>>>>> unrelated to this patch. >>>>>> . >>>>>> It passes on 4.1.1. >>>>>> >>>>>> I'll have to look into the failure but I won't get to it until next >>>>>> week as I'm off the rest of this week. >>>>> >>>>> interesting... If you could post failure signature, I can help >>>>> looking at it, but I guess it's too late to ask :-) >>>>> >>>>> thanks for helping though >>>>> >>>> >>>> >>>> Hi Felipe, >>>> >>>> Nevermind about my issue, it ended up being a setup-related problem. >>>> >>>> I actually do see the same error as you due to this series of patches. >>>> Except I see it happening before even the first iteration. I get a >>>> completion status of 1 for the Set Endpoint Transfer Resources >>>> command. I'm not sure why this is. >>>> >>>> I don't see any conflict with any previous Transfer Complete. >> >> Same behavior at my end too. Fails before first iteration and I get >> completion status of 1 for Set Endpoint Resource command. Attached the >> logs of testing done with this patch and without this patch. >> Without this patch I often see completion status of 1 for Set Endpoint >> Transfer Resources command for Bulk and Isoc endpoints but test >> proceeds because driver just logs command completion status and moves >> on. We can revert this patch for time being. IP version is 2.90a. > > yeah, that's what I mean, it really seems like it's the IP misbehaving. > > John, let's try to figure out what's the root cause of this, we really > want to use command completion status at some point, but for now we need > to revert the patch :-( > > Let me know if you want me to log STARS ticket on your solvnet system. > > cheers > Hi Felipe, We found the issue last week. The start config command isn't getting called during SET_INTERFACE. Thus the transfer resource index isn't getting reset, and with multiple SET_INTERFACE commands it will eventually exhaust the resources. I tried out a fix and it works for me. I'll send it out separately for review. Also, I noticed that the trace message that shows control transfers doesn't show the SET_INTERFACE properly. Any idea why this is? For example, here is the line in the trace that corresponds to the SET_INTERFACE: irq/33-dwc3-10808 [003] d... 2443.494368: dwc3_ctrl_req: bRequestType 01 bRequest 0b wValue 0001 wIndex 0000 wLength 0 John -- 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/