Received: by 10.223.185.116 with SMTP id b49csp5990418wrg; Wed, 28 Feb 2018 02:00:45 -0800 (PST) X-Google-Smtp-Source: AH8x227qbVB5zUUlMsS0aC+OhiRseLEkDP9cLGhiC9RU2Yfna8K+26d18v1u5YDWqCl20rBmEmfO X-Received: by 10.98.147.156 with SMTP id r28mr17329871pfk.204.1519812045242; Wed, 28 Feb 2018 02:00:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519812045; cv=none; d=google.com; s=arc-20160816; b=bEOIwyIKs3CZ//Zzuico/EpQ8KUQ9Pm9Y/Wj7j8nWqHXcXGBXpTjGbnjeAiOboqwlq uIRvvdVbpIhZbSJnG/HKTtDOgIEeem+cOqaVvFtWXsyCOa8ElbnbCT6a6jNyF0HTLquE moiMC+rxCJrsz5+r5VbsMGRV7qEt8zbj41VkoQlzWjlfxKYKrxQDHsrD+Th6ks4JJkoO rrTFNlZhbsJdxJzLGHVPj1p9omGv/rxoeb5+Z0gPd33t48AtoabxmE6oZcSmhftfnISr lBiNWfcQlL3AQhxJo2Lm3Lpk47tlO/kOxmmjexKIJimGMcmSv9m1t8YzI5RNRgqkUgv0 dEeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=vC+TePTyUPHy6niL6WQEeq3UQCsouat1gD6mm0a2fy4=; b=R4u9v1P20D4UkNL9jH5eY5uPsa+UyMblFExpvHwGR0LNvlpDyg8pzd/2GMVYTTXbUY R38egvj8FtiGb7r8wjn3/719hR8F1r0Opn/IrQ+2Gq1NuCf6zcrAIqe/1JSbvFIkzKV5 GwdW8l1NvyLTY69NDn5R2akOYr1bxBniI04cJFX9xbyh7aPyGNfRndrXixPjsQaaKi4C YlRN236SYQL40oXpswzglowC9ofQRs8IfDSSeLWjLdcBKmsCV6oy5l2431JoIJqB3NR4 iKb4oTDZVdyXAW8pdnmoCwW3yqLXlOsWFZHIo2o7k7/ad73NDeWWPZBAz0E6P+ReFWIy OTPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=bn+nOpP0; 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=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m12si805524pgu.590.2018.02.28.02.00.28; Wed, 28 Feb 2018 02:00:45 -0800 (PST) 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; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=bn+nOpP0; 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=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752364AbeB1J7U (ORCPT + 99 others); Wed, 28 Feb 2018 04:59:20 -0500 Received: from fllnx210.ext.ti.com ([198.47.19.17]:60781 "EHLO fllnx210.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752066AbeB1J7S (ORCPT ); Wed, 28 Feb 2018 04:59:18 -0500 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by fllnx210.ext.ti.com (8.15.1/8.15.1) with ESMTP id w1S9xHMj009459; Wed, 28 Feb 2018 03:59:17 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1519811957; bh=89r8QOb+th4K4ZsGrU/XIH1mzJjWesTLCimI5G5uflM=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=bn+nOpP0v0a8fpMKCO90/xqZ8/QxaPRenQ4OFf1/NkP2Oep7gnjq7a8GaXk54gdy8 cm+X5QYKc/lHepdhGtY6ys9ADwFLOXkpTt+LTVaMGP8Ab1PMxAhqRWX3bEasXWIv4Q 55OR3OwDwHxo73UCgG1JqRahnNM2QgzsU1YwecCE= Received: from DFLE113.ent.ti.com (dfle113.ent.ti.com [10.64.6.34]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id w1S9xGIs030436; Wed, 28 Feb 2018 03:59:16 -0600 Received: from DFLE102.ent.ti.com (10.64.6.23) by DFLE113.ent.ti.com (10.64.6.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Wed, 28 Feb 2018 03:59:16 -0600 Received: from dlep33.itg.ti.com (157.170.170.75) by DFLE102.ent.ti.com (10.64.6.23) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Wed, 28 Feb 2018 03:59:16 -0600 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id w1S9xFJr003152; Wed, 28 Feb 2018 03:59:15 -0600 Subject: Re: [PATCH] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume To: Felipe Balbi CC: , References: <1519730526-22274-1-git-send-email-rogerq@ti.com> <87sh9l5z4l.fsf@linux.intel.com> From: Roger Quadros Message-ID: <94cd6377-1327-2309-8d69-6ab0de2bdfd4@ti.com> Date: Wed, 28 Feb 2018 11:59:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <87sh9l5z4l.fsf@linux.intel.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-GB Content-Transfer-Encoding: 8bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Felipe, On 28/02/18 09:53, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> 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() >> >> Let's clear the DWC3_EP_END_TRANSFER_PENDING flag on all endpoints >> so we don't wait in dwc3_gadget_stop(). >> >> Signed-off-by: Roger Quadros >> --- >> drivers/usb/dwc3/gadget.c | 14 ++++++++++++++ >> 1 file changed, 14 insertions(+) >> >> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c >> index 2bda4eb..0a360da 100644 >> --- a/drivers/usb/dwc3/gadget.c >> +++ b/drivers/usb/dwc3/gadget.c >> @@ -3273,6 +3273,20 @@ int dwc3_gadget_init(struct dwc3 *dwc) >> >> void dwc3_gadget_exit(struct dwc3 *dwc) >> { >> + int epnum; >> + unsigned long flags; >> + >> + spin_lock_irqsave(&dwc->lock, flags); >> + for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++) { >> + struct dwc3_ep *dep = dwc->eps[epnum]; >> + >> + if (!dep) >> + continue; >> + >> + dep->flags &= ~DWC3_EP_END_TRANSFER_PENDING; >> + } >> + spin_unlock_irqrestore(&dwc->lock, flags); >> + >> usb_del_gadget_udc(&dwc->gadget); >> dwc3_gadget_free_endpoints(dwc); > > free endpoints is a better place for this. It's already going to free > the memory anyway. Might as well clear all flags to 0 there. > But it won't solve the deadlock issue. Since dwc3_gadget_free_endpoints() is called after usb_del_gadget_udc() and the deadlock happens when usb_del_gadget_udc()->udc_stop()->dwc3_gadget_stop()->wait_event_lock_irq() and DWC3_EP_END_TRANSFER_PENDING flag is set. -- cheers, -roger Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki