Received: by 10.223.185.116 with SMTP id b49csp2392351wrg; Mon, 5 Mar 2018 01:58:44 -0800 (PST) X-Google-Smtp-Source: AG47ELvBZOthlYxXX8qRf125Y0osfy9fpty5k5LBBo6nyeLw8D9SnlQ/UQofJePm8G6Axz4UdVP0 X-Received: by 10.101.74.10 with SMTP id s10mr12085944pgq.219.1520243924038; Mon, 05 Mar 2018 01:58:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520243923; cv=none; d=google.com; s=arc-20160816; b=QnpU8xSxDGYWe1NMd+hmW5uAneiCm/TDqqrGiGeBE7jTtUmZTD45fzwGGymoVUo6ed 85mKlkzmPemc0sr0XKbyxB3OzLX88uGHDIrIA1PvMcIZWlMmL2zhWmSLXh3TxlmQQFhP wNXWXLS8BwYx9B0DqdhhBSffqygyC/2ft3T1WlbpGpDFuu394yLMG/7bYLXEUN5gKSYB 249i+iaTmIIjuVzm0e5Ifv2g64JIx9xMDRs683V0nBLbqdEC+9ThY/m99NQ7E1niMTA9 ZN9GHc734SjioSM0H5fER9cwa96v7lXfEDwq25yjH27S30xUwEiAiJVrFlWydLh7RGQ+ mPIA== 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=ovbViNcYygjlbCpgbSbf6HoMaKltH62V8mh7Ey8/5w0=; b=Q92U5RGS60Icx4OBKsuJLVbJPqBWTfumT/PWiBGTGsuEeR1Fy1SEuZWygfi6TsqT5V A+gL5r6W+ICV3YNcH0vuLeQhVakp7/2nTnwM+DTHy2KeviVWuGTjZvX67CuD2MAq4isS N8fVHRrNo8eFJcoTkhNBHafGRta8EHry23rUPGRz60mlBmcHFx2aL6h+snnMUjzygYOH LPUvMVkzc/Mlns4uV2sYcUrmQJ8COFELC/XDCfCCcK6jTuhOe154+MLx38RqgvSiSwmf Ik6bYqqK8+J7k+6oemcka1e8/2RM5Y6TbQFG5s2H4d48e93jN/Qv9exTG0JBRJxO4m0A AefQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=sifdjx9G; 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 g11si8175527pgf.5.2018.03.05.01.58.29; Mon, 05 Mar 2018 01:58:43 -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=sifdjx9G; 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 S933489AbeCEJqI (ORCPT + 99 others); Mon, 5 Mar 2018 04:46:08 -0500 Received: from lelnx193.ext.ti.com ([198.47.27.77]:53267 "EHLO lelnx193.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933048AbeCEJqC (ORCPT ); Mon, 5 Mar 2018 04:46:02 -0500 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by lelnx193.ext.ti.com (8.15.1/8.15.1) with ESMTP id w259k0GF019558; Mon, 5 Mar 2018 03:46:00 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1520243160; bh=MZuo7WEZPrCNVBDlnu1HrbfWZ8SEHS2OS4YAXr16ArY=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=sifdjx9GYO5n46Z2e30ABlnWIpLE7zA2kPEttT7nqJ7qAcqpyrtD6XHrN4Z40ya77 z+QdpnExHb9jncDg5bo5I/PusOICI4eIddjtDMB7kSTp0FLBupIgaysVsXfgpbZMpY 9lTyiEKNx0GMBU4qpzs3nU3+IeK6dLk2zX5fN7qo= Received: from DFLE106.ent.ti.com (dfle106.ent.ti.com [10.64.6.27]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id w259k0R4032675; Mon, 5 Mar 2018 03:46:00 -0600 Received: from DFLE113.ent.ti.com (10.64.6.34) by DFLE106.ent.ti.com (10.64.6.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Mon, 5 Mar 2018 03:45:59 -0600 Received: from dlep32.itg.ti.com (157.170.170.100) by DFLE113.ent.ti.com (10.64.6.34) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Mon, 5 Mar 2018 03:45:59 -0600 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id w259jwtB019222; Mon, 5 Mar 2018 03:45:58 -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> <94cd6377-1327-2309-8d69-6ab0de2bdfd4@ti.com> <87po4i3o1v.fsf@linux.intel.com> From: Roger Quadros Message-ID: Date: Mon, 5 Mar 2018 11:45:58 +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: <87po4i3o1v.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 05/03/18 10:49, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >>> 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. > > indeed. Iterating twice over the entire endpoint list seems > wasteful. Perhaps we just shouldn't wait when removing the UDC since > that's essentially what this patch will do, right? If you clear the flag > before calling ->udc_stop(), this means the loop in dwc3_gadget_stop() > will do nothing. Might as well remove it. > This means that we will never wait for DWC3_EP_END_TRANSFER_PENDING to clear in dwc3_gadget_stop() like we used to. This is perfectly fine, right? It makes sense to me as dwc3_gadget_stop() calls __dwc3_gadget_stop() which masks all interrupts and nobody will ever clear that flag if it was set. And there is no point in clearing the DWC3_EP_END_TRANSFER_PENDING flag in dwc3_gadget_free_endpoints() since we're freeing the dwc3_ep memory there. dwc3_gadget_init_endpoints() will start with a clean slate. -- cheers, -roger Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki