Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp5786998pxb; Tue, 16 Feb 2021 07:36:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJxKXwqXkoC9q1CRe+pYzkKXyM8WHLDDllAM7+mzESofUQJEscM/LlyjZIr0rGHsEsDuJ7Dc X-Received: by 2002:a05:6402:208:: with SMTP id t8mr21352771edv.189.1613489808214; Tue, 16 Feb 2021 07:36:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613489808; cv=none; d=google.com; s=arc-20160816; b=LqK/vsNYTiAYA8NcvllwZ9HQULNV7k++YvnQ4AtqDN4vPIFhRtIUeGCuLiCKMTefc6 9HSW0a1Yt3vaXHD4bk9PhPuagJac+srKha2AfKtkGLqHYwqo7WGEiq4ho+M9udwbxtTA uF4mBPxGPsa9VXxFKEN2novoubHIBB4FqAe9PMC59RrOcfH1/yxCpJhw4Gz5qGIzjL8e L+1ZeyXS/RdR/cOU9WFSSmrQ1LKBGZrX8/enS6lT6WeXTMZAR7e5ZxmK+sukXwx5tWOF M0tWxHruS6BlJe24ZlcNE/J1tw5spZEmA9S12TKc7GBvvFsxva2ve2238q4Bf8Dj6l5E f0Qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=4DIDbO44jLHgkt/ehWZZu+CThX3S1n9Z/v/2/as2I2A=; b=LVWRm2kxnj1PAkeR/W44/nHR6CZNFJfzugivTC4MKBqiUUZHx5/vS+wmO2N6nA0M+n hIWrDx+rL+nmsp+yQO7VRAkqQnY1A+yZbakG9CqXqhk/uM0Mc36W7NTm+OXD7v3inWxh 8PzE18oFDBodEyXJy87/eGp1ZQT7rXq7No4GMB8rkl8zJyBRxV2hoZI0iVSYTs5Kn9cx vbZ/0Cl34lJaAOssiE2z/dIuZ/jzi38mwOGRRnx1PgcGrEAzwmnHFOWViGTZ2s17GDlS H0z96WSO/UBAS+UTVfAlu7S+QHkLbXskalLiu1gOkVrlRFyj45D421W5/uwFrmS6tXBo 3QRw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d21si1283344ejr.650.2021.02.16.07.36.24; Tue, 16 Feb 2021 07:36:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230361AbhBPPct (ORCPT + 99 others); Tue, 16 Feb 2021 10:32:49 -0500 Received: from netrider.rowland.org ([192.131.102.5]:60709 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S230261AbhBPPcJ (ORCPT ); Tue, 16 Feb 2021 10:32:09 -0500 Received: (qmail 992341 invoked by uid 1000); 16 Feb 2021 10:31:26 -0500 Date: Tue, 16 Feb 2021 10:31:26 -0500 From: Alan Stern To: eg Kroah-Hartman Cc: Wesley Cheng , Felipe Balbi , "open list:DESIGNWARE USB3 DRD IP DRIVER" , open list Subject: Re: usb: dwc3: gadget: Change runtime pm function for DWC3 runtime suspend Message-ID: <20210216153126.GA991262@rowland.harvard.edu> References: <1613356739-91734-1-git-send-email-dh10.jung@samsung.com> <20210215174145.GA960831@rowland.harvard.edu> <20210216013052.GA37172@ubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210216013052.GA37172@ubuntu> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 16, 2021 at 10:30:52AM +0900, Jung Daehwan wrote: > Hello, Alan > > On Mon, Feb 15, 2021 at 12:41:45PM -0500, Alan Stern wrote: > > On Mon, Feb 15, 2021 at 11:38:58AM +0900, Daehwan Jung wrote: > > > It seems pm_runtime_put calls runtime_idle callback not runtime_suspend callback. > > > > How is this fact related to your patch? > > I think we should cause dwc3_runtime_suspend at the time. Why do you think so? > That's why I use pm_runtime_put_sync_suspend. > > > > > > It's better to use pm_runtime_put_sync_suspend to allow DWC3 runtime suspend. > > > > Why do you think it is better? The advantage of pm_runtime_put is that > > it allows the suspend to occur at a later time in a workqueue thread, so > > the caller doesn't have to wait for the device to go into suspend. > > > > We can assume DWC3 was already in suspend state if pm_runtime_get_sync > returns 0. DWC3 resumes due to pm_rumtime_get_sync but it doesn't > re-enter runtime_suspend but runtime_idle. pm_runtime_put decreases > usage_count but doesn't cause runtime_suspend. > > 1. USB disconnected > 2. UDC unbinded > 3. DWC3 runtime suspend > 4. UDC binded unexpectedly > 5. DWC3 runtime resume (pm_runtime_get_sync) > 6. DWC3 runtime idle (pm_runtime_put) > -> DWC3 runtime suspend again (pm_runtime_put_sync_suspend) That's what happens with your patch. Now look at what happens without the patch: 1. USB disconnected 2. UDC unbound 3. DWC3 suspend request is added to waitqueue 4. UDC bound unexpectedly 5. DWC3 suspend request is removed from waitqueue 6. DWC3 runtime idle 7. DWC3 runtime suspend The difference is that this way, we avoid doing an unnecessary suspend and resume, and we save the time they would have required. > I've talked with Wesley in other patch. > > usbb: dwc3: gadget: skip pullup and set_speed after suspend > patchwork.kernel.org/project/linux-usb/patch/1611113968-102424-1-git-send-email-dh10.jung@samsung.com > > @ Wesley > > I think We should guarantee DWC3 enters suspend again at the time. Why do you think we should guarantee this? Alan Stern