From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A62F4C43334 for ; Wed, 13 Jul 2022 02:56:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233919AbiGMC4w (ORCPT ); Tue, 12 Jul 2022 22:56:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59518 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233634AbiGMC4r (ORCPT ); Tue, 12 Jul 2022 22:56:47 -0400 Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FB12D64D7; Tue, 12 Jul 2022 19:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1657681006; x=1689217006; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=j+pIU+Vim4PMSxlEaF3xva7X5PqjxMIjOw7jLEzSTsU=; b=cmykBuR6rAfi1BkTf6UhoatwBC6RVRou7GeU4yYsI6zXQDpUxd2rg9H4 DRLKBv5YE6McwJafsmcD6B7VmWZuItwS7Tq6mR3fUa9u+bKnZ5g55N2Xz /1QrZNJUCb92ctvKBseFi3S92wTqZa6nbHgEhnaH9xSYSN1UxSSvflLo+ c=; Received: from unknown (HELO ironmsg02-sd.qualcomm.com) ([10.53.140.142]) by alexa-out-sd-01.qualcomm.com with ESMTP; 12 Jul 2022 19:56:46 -0700 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg02-sd.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2022 19:56:45 -0700 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Tue, 12 Jul 2022 19:56:45 -0700 Received: from jackp-linux.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Tue, 12 Jul 2022 19:56:44 -0700 Date: Tue, 12 Jul 2022 19:56:43 -0700 From: Jack Pham To: Wesley Cheng CC: , , , , Subject: Re: [PATCH v2 5/5] usb: dwc3: gadget: Increase DWC3 controller halt timeout Message-ID: <20220713025643.GC8200@jackp-linux.qualcomm.com> References: <20220713003523.29309-1-quic_wcheng@quicinc.com> <20220713003523.29309-6-quic_wcheng@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20220713003523.29309-6-quic_wcheng@quicinc.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Wesley, On Tue, Jul 12, 2022 at 05:35:23PM -0700, Wesley Cheng wrote: > Since EP0 transactions need to be completed before the controller halt > sequence is finished, this may take some time depending on the host and the > enabled functions. Increase the controller halt timeout, so that we give > the controller sufficient time to handle EP0 transfers. > > Fixes: 861c010a2ee1 ("usb: dwc3: gadget: Refactor pullup()") > Suggested-by: Thinh Nguyen > Signed-off-by: Wesley Cheng > --- > Link: > https://lore.kernel.org/linux-usb/4988ed34-04a4-060a-ccef-f57790f76a2b@synopsys.com/ > > drivers/usb/dwc3/gadget.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > index 41b7007358de..e32d7293c447 100644 > --- a/drivers/usb/dwc3/gadget.c > +++ b/drivers/usb/dwc3/gadget.c > @@ -2476,6 +2476,7 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend) > dwc3_gadget_dctl_write_safe(dwc, reg); > > do { > + msleep(1); Be aware that this probably won't sleep for *just* 1ms. From Documentation/timers/timers-howto.rst: msleep(1~20) may not do what the caller intends, and will often sleep longer (~20 ms actual sleep for any value given in the 1~20ms range). In many cases this is not the desired behavior. So with timeout==500 this loop could very well end up iterating for up to 10 seconds. Granted this shouldn't be called from any atomic context but just wanted to make sure that the effective increase in timeout as $SUBJECT intends is made clear here and that it's not overly generous. > reg = dwc3_readl(dwc->regs, DWC3_DSTS); > reg &= DWC3_DSTS_DEVCTRLHLT; > } while (--timeout && !(!is_on ^ !reg)); Jack