Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp362869rwe; Wed, 24 Aug 2022 02:13:20 -0700 (PDT) X-Google-Smtp-Source: AA6agR4sc44DpTtSt1qgdPHZsfGP+WOrsVV1DVpVPWvajUNRT5xmQkdQ3aDFQpwfv96/KZO0uXAd X-Received: by 2002:a17:903:26d3:b0:173:984:c2e4 with SMTP id jg19-20020a17090326d300b001730984c2e4mr5084557plb.108.1661332400421; Wed, 24 Aug 2022 02:13:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661332400; cv=none; d=google.com; s=arc-20160816; b=n0UrqWpHThGhATk/XR9/nZvYBs1jr24lkyXMBcoZ1xdINZH7NThXQt1xXrRP854+8J zR2ujorTuXIYuqPG5i0Ijdx3GHgm1/wBXaY/0Wi96t6Oweuuk4K78HqB28VzO9E+fC4a f0fa6xXZZGFnPoea9waY84nyf8pce1rWTa2oCY9sgn7itBgxOCHSTwIp03n7aYLkhAhb tedV+PsI6HZ+R8FaEATVBrNtJueSv3JezQKweCzeRPVB+UnhQhLZFZhf0CPVR17Z7YWs hkCXU+/B2aK1FODNisv6Ypvnf0TlGPGTXUsf5eEIFjc7o7uKiwNUepvLWy9q4VflJyuB HTNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=02wiinMVYQ8ttb5BJTE0tUX2yCErUm5SZBdlcJZJG50=; b=e1Irgnp7s4mnegwmJx1J6Mhe879iXWxOxg+fMQL2xfKTHLyexPeuZzmPP++EwmcwhN f+NU3QIb+hO9H1OI4s+6eVZrsOSLN/C1oA8UoOx/SyeXJsHsw+IhysVkVTgdfCG+d+nv WG3lE7TrgnRW2xWV1bTO5Q53f0DpSjEwogIVoYl+q8/+1LfLKVODHH2TEgph2icALpks bgU0aDmeBvCUAqUNk/pyAGLkkhnJYWlcu3pKbywqVMfT+IB5JpY3Rb08grAbdXypqvzL XREUjj7qxNKEcFTfZFMmv90yQLrCBsKI0E5HMnyZ9FugMgGzkf4bV7puR4ux2HBUg6vk /fug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="rns/zYsL"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x186-20020a6386c3000000b0042b26627266si615907pgd.457.2022.08.24.02.13.09; Wed, 24 Aug 2022 02:13:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="rns/zYsL"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235809AbiHXI14 (ORCPT + 99 others); Wed, 24 Aug 2022 04:27:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38744 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235729AbiHXI1r (ORCPT ); Wed, 24 Aug 2022 04:27:47 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0426E93230; Wed, 24 Aug 2022 01:27:44 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 3AC0CB8238E; Wed, 24 Aug 2022 08:27:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7C61C433B5; Wed, 24 Aug 2022 08:27:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661329661; bh=Cswsg5zwfQnIxDqhYpbvzbjzMba7/Q3SMHSTlIl4nr8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rns/zYsL6l6/nzNgn6OPoDzXGQ9O4PkTAx4ahpmezNfDqJO5X2igsp3OWb0tBrUgL od/SBuxqloB/0+k6Urdah49vznJ4jlaF2N1un/Vmv/dW6hpLveHekjs3OZ0vOjybsh 2lBgIS7aVUUfSARtNBrmNU2YUMqim/pgq/fTwmh0HxyLBN2gncoWfD3bjvag7iF/4+ WRbUtcdS9S8cgb7z2nfnIHDgObqFywt5sNHEUAus1Qu2RcGBDu0YXI9qRQj07cVa2S 7lKCYTdMROFIuwSV0YKqE4WBDL0gEGJuptFAYhF1V2/XnIh0yJTNkNFGOzG1f8wfC0 vU9YZHWbf+zbw== Received: from johan by xi.lan with local (Exim 4.94.2) (envelope-from ) id 1oQljk-0003G4-4G; Wed, 24 Aug 2022 10:27:44 +0200 Date: Wed, 24 Aug 2022 10:27:44 +0200 From: Johan Hovold To: Matthias Kaehlcke Cc: Johan Hovold , Greg Kroah-Hartman , Felipe Balbi , Andy Gross , Bjorn Andersson , Konrad Dybcio , Krishna Kurapati , Pavankumar Kondeti , linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] usb: dwc3: keep PHYs disabled during suspend Message-ID: References: <20220823124047.14634-1-johan+linaro@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 23, 2022 at 11:33:18AM -0700, Matthias Kaehlcke wrote: > Hi Johan, > > On Tue, Aug 23, 2022 at 02:40:47PM +0200, Johan Hovold wrote: > > Commit 649f5c842ba3 ("usb: dwc3: core: Host wake up support from system > > suspend") started leaving the PHYs enabled during suspend for > > wakeup-capable controllers even though it turns out this had nothing to > > do with wakeup. > > > > Rather, the wakeup capability flag was (ab-)used as a proxy to configure > > the suspend behaviour in an attempt to reduce power leakage on some > > platforms. > > > > Stop abusing the wakeup configuration and restore the 5.19 behaviour of > > keeping the PHYs powered off during suspend. If needed, a dedicated > > mechanism for configuring the PHY power state during suspend can be > > added later. > > > > Fixes: 649f5c842ba3 ("usb: dwc3: core: Host wake up support from system suspend") > > Link: https://lore.kernel.org/r/Yuv7AM/5jtO/pgcm@google.com > > Signed-off-by: Johan Hovold > > --- > > drivers/usb/dwc3/core.c | 4 ++-- > > drivers/usb/dwc3/dwc3-qcom.c | 1 - > > 2 files changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > > index 8c8e32651473..0cdb6be720e1 100644 > > --- a/drivers/usb/dwc3/core.c > > +++ b/drivers/usb/dwc3/core.c > > @@ -1983,7 +1983,7 @@ static int dwc3_suspend_common(struct dwc3 *dwc, pm_message_t msg) > > dwc3_core_exit(dwc); > > break; > > case DWC3_GCTL_PRTCAP_HOST: > > - if (!PMSG_IS_AUTO(msg) && !device_may_wakeup(dwc->dev)) { > > + if (!PMSG_IS_AUTO(msg)) { > > My assumption was that the PHYs need to be powered for wakeup to work, but > apparently that isn't the case, wakeup still works on sc7x80 with this part > of this patch. Thanks for confirming. > > dwc3_core_exit(dwc); > > break; > > } > > @@ -2044,7 +2044,7 @@ static int dwc3_resume_common(struct dwc3 *dwc, pm_message_t msg) > > spin_unlock_irqrestore(&dwc->lock, flags); > > break; > > case DWC3_GCTL_PRTCAP_HOST: > > - if (!PMSG_IS_AUTO(msg) && !device_may_wakeup(dwc->dev)) { > > + if (!PMSG_IS_AUTO(msg)) { > > ret = dwc3_core_init_for_resume(dwc); > > if (ret) > > return ret; > > diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c > > index 9a94b1ab8f7a..9995395baa12 100644 > > --- a/drivers/usb/dwc3/dwc3-qcom.c > > +++ b/drivers/usb/dwc3/dwc3-qcom.c > > @@ -904,7 +904,6 @@ static int dwc3_qcom_probe(struct platform_device *pdev) > > > > wakeup_source = of_property_read_bool(dev->of_node, "wakeup-source"); > > device_init_wakeup(&pdev->dev, wakeup_source); > > - device_init_wakeup(&qcom->dwc3->dev, wakeup_source); > > Surprisingly this part breaks wakeup on sc7x80, with the above removal > of the device_may_wakeup() checks it is not clear to me why wakeup needs > to be enabled for the core. I can't explain that behaviour either. This change doesn't affect the wakeup_path flag and genpd, and notably wakeup still works here with sc8280xp. Could it be some Chromium user-space issue in that it expects all devices on the wakeup path to be wakeup capable? Note that the xhci-plat driver (e.g. for the descendant xhci-hcd.1.auto device) unconditionally sets the wakeup-capable flag (but leaves it disabled by default). I guess we could do something similar for the dwc3 core device, but we'd need to figure out if and why that is at all needed first. Can you verify that the wakeup source (e.g. keyboard) you're using still has power/wakeup set to "enabled"? Johan