Received: by 10.213.65.68 with SMTP id h4csp335683imn; Fri, 16 Mar 2018 04:46:54 -0700 (PDT) X-Google-Smtp-Source: AG47ELsV20Z1qXf7/pz+ZCELwhoSYSA9wZgA/RfD5VWdLokmmlxU5bK2ZDwKzMVe9ANIDuMUb3g5 X-Received: by 10.98.38.133 with SMTP id m127mr1355582pfm.122.1521200814662; Fri, 16 Mar 2018 04:46:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521200814; cv=none; d=google.com; s=arc-20160816; b=MT8Xa5PbJaj1nWddHvfJt9WDanml1R/lqOztpseJHDy8RuYo0c2OX90hE1eM2sBrqR bZGJUrGDQn/P5MXBpqKm2C6hnyr3XgZjyC7rharXf1Vrx1CJtNE6lbG9QmcrKkV9wS6x FJO1TQeObTWMeh+eixbHOyLWKJDqXPmBGz4Hcxrimxv6rqJMm2Qnn1AKaTVdknMT1z+1 YA8tIJIb+mKFjuZQ3R0lDwyUmNr8I6gATlfz6ME+Cc92snUrS3GG+OY0CB8onizYmtOX 7WLdGoUS6O7TXLBCqx11Zm3W5lKl9VtNhkAKYJYjvmwoyXBBRkYx6Oh4ZLRsZfeIop52 gXVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:references:message-id:date :thread-index:thread-topic:subject:cc:to:from :arc-authentication-results; bh=1DipYDEB5sHSc1BSgzpPCcYyGGKAoqHEvudGFMtRUc4=; b=gsgIUEXvlatP70AsDlcCC7e9HUpB8Mez/GJRnK8hcynljBC8mRMz5Y0mAV+RGiBFK6 g+URDJ6v7JURCUQ+BYVcCTGihnTZP1sYDZBNO3mnVHYCvRuPsrSdu8vTdQWvFUHXr7Cu 8dzAaaiAYA/1siVjQtPJ4hXcDEXHUFiMrRXQDxYK0fJJzrJ6QohaNIeKtDB/8r6LCHtq L++CazArhBuJAFzNbXvt0RiYpjZETWyqy7PyD0JDVGogOKmAek1qbIk6Cq/p3dcs/2CQ 0MWIIXywRVp2v7m+9uRXFzUCpPEh7DhTdGsHKM02aIZFAJTyMAqBYi8tD9JWbrXM+q+W ceVQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=synopsys.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f69si5432042pfd.196.2018.03.16.04.46.09; Fri, 16 Mar 2018 04:46:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=synopsys.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753297AbeCPLni convert rfc822-to-8bit (ORCPT + 99 others); Fri, 16 Mar 2018 07:43:38 -0400 Received: from smtprelay.synopsys.com ([198.182.60.111]:60491 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751888AbeCPLng (ORCPT ); Fri, 16 Mar 2018 07:43:36 -0400 Received: from mailhost.synopsys.com (mailhost3.synopsys.com [10.12.238.238]) by smtprelay.synopsys.com (Postfix) with ESMTP id 4832B10C063D; Fri, 16 Mar 2018 04:43:36 -0700 (PDT) Received: from mailhost.synopsys.com (localhost [127.0.0.1]) by mailhost.synopsys.com (Postfix) with ESMTP id 2B0BC32AC; Fri, 16 Mar 2018 04:43:36 -0700 (PDT) Received: from US01WXQAHTC1.internal.synopsys.com (us01wxqahtc1.internal.synopsys.com [10.12.238.230]) by mailhost.synopsys.com (Postfix) with ESMTP id 113D032AB; Fri, 16 Mar 2018 04:43:36 -0700 (PDT) Received: from AM04WEHTCA.internal.synopsys.com (10.116.16.190) by US01WXQAHTC1.internal.synopsys.com (10.12.238.230) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 16 Mar 2018 04:43:35 -0700 Received: from AM04WEMBXA.internal.synopsys.com ([fe80::79c3:55f2:1f20:5bf4]) by am04wehtca.internal.synopsys.com ([::1]) with mapi id 14.03.0361.001; Fri, 16 Mar 2018 15:43:33 +0400 From: Minas Harutyunyan To: Roger Quadros , Felipe Balbi CC: "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume Thread-Topic: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume Thread-Index: AQHTt7VttcDOmDIowUqzUI1Hi/JpmA== Date: Fri, 16 Mar 2018 11:43:32 +0000 Message-ID: <410670D7E743164D87FA6160E7907A560113ABB478@am04wembxa.internal.synopsys.com> References: <1519730526-22274-1-git-send-email-rogerq@ti.com> <69517684-bd39-e945-0c9e-ccd52b8050d5@ti.com> <87y3isffog.fsf@linux.intel.com> <5ea0ad17-d538-72ec-ed59-004242c4cd26@ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.70.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 3/16/2018 3:03 PM, Roger Quadros wrote: > On 16/03/18 13:00, Felipe Balbi wrote: >> >> Hi, >> >> Roger Quadros writes: >> >>> Hi Felipe, >>> >>> On 09/03/18 14:47, Roger Quadros wrote: >>>> In the following test we get stuck by sleeping forever in _dwc3_set_mode() >>>> after which dual-role switching doesn't work. >>>> >>>> On dra7-evm's dual-role port, >>>> - Load g_zero gadget driver and enumerate to host >>>> - suspend to mem >>>> - disconnect USB cable to host and connect otg cable with Pen drive in it. >>>> - resume system >>>> - we sleep indefinitely in _dwc3_set_mode due to. >>>> dwc3_gadget_exit()->usb_del_gadget_udc()->udc_stop()-> >>>> dwc3_gadget_stop()->wait_event_lock_irq() >>>> >>>> To fix this instead of waiting indefinitely with wait_event_lock_irq() >>>> we use wait_event_interruptible_lock_irq_timeout() and print >>>> and error message if there was a timeout. >>>> >>>> Signed-off-by: Roger Quadros >>> >>> Thanks for picking this for -next. >>> Is it better to have this in v4.16-rc fixes? >>> and also stable? v4.12+ >> >> Well, there was no "Fixes: foobar" or "Cc: stable" lines in the commit >> log ;-) >> >> The best we can do now, is wait for -rc1 and manually send the commit to >> stable. >> > > That's fine. Thanks. > Same issue seen in dwc3_gadget_ep_dequeue() function where also used wait_event_lock_irq() - as result infinite loop. Actually to fix this issue I updated condition of wait function from: !(dep->flags & DWC3_EP_END_TRANSFER_PENDING) to: !(dep->flags & DWC3_EP_END_TRANSFER_PENDING & DWC3_EP_ENABLED) Not, sure that this fix is fully correct because I'm familiar with dwc3, but this fix allow us to go forward with request dequeue. I think, need deeper investigation of infinite loop to catch root cause of it, before accept any of fixes. Thanks, Minas