Received: by 10.213.65.68 with SMTP id h4csp1132627imn; Thu, 22 Mar 2018 16:23:36 -0700 (PDT) X-Google-Smtp-Source: AG47ELuyU3muGfmvmVV0Kzrci1K57d5SfOdsT/A7BjlUSj5JCRmZzkEo6epS5TQbF48Yo5bR05TN X-Received: by 2002:a17:902:128c:: with SMTP id g12-v6mr26432869pla.98.1521761016636; Thu, 22 Mar 2018 16:23:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521761016; cv=none; d=google.com; s=arc-20160816; b=eAuMlhFB+7+dCBhZIh6fQwB9NBhb2yWzJ51NOUxqxD8OwaoHJvtRx6amninfKBerlR vIuNcOOX81Y0W3cSreCUZZmCOEiTp4RbQHLN0AMSKOkxRqYlLn3374DpcYDxKA4GMCZU QoVpTghrTgdhBIyIzXzRReoXuc9zpQdqounsyK/lwVAC1wqBDcyhye/bL1uUgJVBdq66 fGlt3q3GJsoePEw69kx1ycJNVcjOOiOjbwYlNOoD+qMRR32Rc2BtpJp/R7qNIBTCBca+ AdWP0BQjU9sl5wjWOt/H2gvMlO5RpeRQ1Tt2sbqflOsHQTXGpYWG3FZvulT1eGJwUfJf ppLA== 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:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=QESZyW0hEJSNm0jg7iS37gvgAHREh+67uoUlAYoNd30=; b=WkgsWDITRiSvNjyYP+Q+ri027uGlOrcq1Ik0bH9H8Fx72GIFUvtNayb/kT0BFCgFvy j1dwwwkfaziGP/XS723/ThweEDiXCt47DhUGv7CE1Ke50GIt9d0+spleR4/w++ua4vrV Tb4SA44V++8BQJlZkuhwd0yEkFmEvuyNDStVOzUrxlIkAlL5Jb5nUZnzm8IphYHO3Jzo o3VEuAK9yLH5yn1wXcD+3HTO+w//UA/o1fkxGd6WTkQKRiEIUDud0qi+Q3VhH+/ERec0 oqEpNGbK0YK5Wnxw+njqmtq/X4Jl1E7ueerApwR7vzQ8SP/mq+OoaZ60pRPwbqEEH7r8 TbxA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k8-v6si7141643pli.7.2018.03.22.16.23.22; Thu, 22 Mar 2018 16:23:36 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752097AbeCVXWF (ORCPT + 99 others); Thu, 22 Mar 2018 19:22:05 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:43460 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751715AbeCVXWD (ORCPT ); Thu, 22 Mar 2018 19:22:03 -0400 Received: from 79.184.254.228.ipv4.supernova.orange.pl (79.184.254.228) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83) id c4614142877b0b08; Fri, 23 Mar 2018 00:22:01 +0100 From: "Rafael J. Wysocki" To: Daniel Drake Cc: lenb@kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linux@endlessm.com, chiu@endlessm.com, mathias.nyman@intel.com, linux-usb@vger.kernel.org Subject: Re: [PATCH v2] ACPI / PM: allow deeper wakeup power states with no _SxD nor _SxW Date: Fri, 23 Mar 2018 00:22:27 +0100 Message-ID: <3441706.zTHvev0s8F@aspire.rjw.lan> In-Reply-To: <20180320040735.13025-1-drake@endlessm.com> References: <20180320040735.13025-1-drake@endlessm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, March 20, 2018 5:07:35 AM CET Daniel Drake wrote: > acpi_dev_pm_get_state() is used to determine the range of allowable > device power states when going into S3 suspend. This is implemented > by executing the _S3D and _S3W ACPI methods. > > Linux follows the ACPI spec behaviour in that when _S3D is implemented > and _S3W is not, Linux will not go into a power state deeper than the one > returned by _S3D for a wakeup-enabled device. > > However, this same logic is being applied to the case when neither > _S3D nor _S3W are present, and the result is that this function > decides that the device must stay in D0 (fully on) state. > > This is breaking USB wakeups on Asus V222GA and Acer XC-830. _S3D and > _S3W are not present, so the USB controller is left in the D0 running > state during S3, and hence it is unable to generate a PME# wake event. > > The ACPI spec is unclear on which power states are permissable for > wakeup-enabled devices when both _S3D and _S3W are missing. > However, USB wakeups work fine on these platforms under Windows, where > device manager shows that they are using D3 device state for the USB > controller in S3. > > I assume that the "max = min" clamping done by the code here is > specifically written for the _S3D but no _S3W case. By making the > code true to those conditions, avoiding them on these platforms, > the controller will be put into D3 state and USB wakeups start working. > > Additionally I feel that this change makes the code more directly > mirror the wording of the ACPI spec and it's associated lack of clarity. > > Thanks to Mathias Nyman for pointing us in the right direction. > > Signed-off-by: Daniel Drake > Link: http://lkml.kernel.org/r/CAB4CAwf_k-WsF3zL4epm9TKAOu0h=Bv1XhXV_gY3bziOo_NPKA@mail.gmail.com > > https://phabricator.endlessm.com/T21410 > --- > > Notes: > This should be considered for Linux 4.17 to give it a decent amount > of testing time before release. > > v2: fix unused variable warning > > drivers/acpi/device_pm.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c > index c4d0a1c912f0..3d96e4da2d98 100644 > --- a/drivers/acpi/device_pm.c > +++ b/drivers/acpi/device_pm.c > @@ -543,6 +543,7 @@ static int acpi_dev_pm_get_state(struct device *dev, struct acpi_device *adev, > unsigned long long ret; > int d_min, d_max; > bool wakeup = false; > + bool has_sxd = false; > acpi_status status; > > /* > @@ -581,6 +582,10 @@ static int acpi_dev_pm_get_state(struct device *dev, struct acpi_device *adev, > else > return -ENODATA; > } > + > + if (status == AE_OK) > + has_sxd = true; > + > d_min = ret; > wakeup = device_may_wakeup(dev) && adev->wakeup.flags.valid > && adev->wakeup.sleep_state >= target_state; > @@ -599,7 +604,11 @@ static int acpi_dev_pm_get_state(struct device *dev, struct acpi_device *adev, > method[3] = 'W'; > status = acpi_evaluate_integer(handle, method, NULL, &ret); > if (status == AE_NOT_FOUND) { > - if (target_state > ACPI_STATE_S0) > + /* No _SxW. In this case, the ACPI spec says that we > + * must not go into any power state deeper than the > + * value returned from _SxD. > + */ > + if (has_sxd && target_state > ACPI_STATE_S0) > d_max = d_min; > } else if (ACPI_SUCCESS(status) && ret <= ACPI_STATE_D3_COLD) { > /* Fall back to D3cold if ret is not a valid state. */ > Applied, thanks!