Received: by 10.213.65.68 with SMTP id h4csp98248imn; Mon, 19 Mar 2018 21:08:52 -0700 (PDT) X-Google-Smtp-Source: AG47ELtovKm046hWTy8/Q/JVSMe6Gw98Y30jnbIae2CL+sYKWhocxpXY8UjxWWo1SaVwoabHDCNL X-Received: by 2002:a17:902:7787:: with SMTP id o7-v6mr15078117pll.75.1521518932348; Mon, 19 Mar 2018 21:08:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521518932; cv=none; d=google.com; s=arc-20160816; b=g3DX9AYwzEESPfuCTihNp5i16+mWJXM2bASKaNEwJv4pZMurCIByOcUF5uP5Jr2wpC Uco6wMvuNx06wOdpDYfycYQYrloSlMKZd0ULebPsWmz4XCdazTdC+orJQSDz3zdhumxi qT550rqC8WDupHoWe6+J3WyNrFShtd59xwMBzYQWad1IJLYOi7b8uPcEz014s8k80BsB kZXwUEB/brDNHdW7hX+6mtFoDeqAty1ENRLVwkhHVyEBjfF0Qm7fDPoL92GeNDJzfWOU 5MXKYD5+p/sZsXwpiC6bIOpALpM2IeHFsT4g5d/r6sneVjrJgDTU8cAjAdudXqP1XQ11 N3Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=68c/3p+sAYdTqA2qQx3+c8hXrfuiOPFZsM1LWEB3hMI=; b=Y2bwpWfKD96FCc4isc1ZdLUZQ52XkNxeXiMOg/zJSJit1sLVNiEx3EjVTuqq3twTHV pJjR6ftDkMCjHrfzHUBPC16My/TNrcbUO5qiuQf4h6Xq2F7nGd0S9FfTX3nlhM+mlPdR GSvagYid5LKl4G68xsoGRC+Saa758rnOAD6q0TaJG3S+str+MGdZEUYzAtQPoLtUeiC/ MAc3wsbKKba8Rrmn71g7xmWkZKiWSBfF1zjOsC/MbU1ik/V11dOYx1bDk70EiK+razk1 Vy4T74LJapXay2bg96ACpxZ5iCdN2hr3K2wJPs5PKFFK014J8JxbH1XMQmTTb0NCkF67 aBNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@endlessm-com.20150623.gappssmtp.com header.s=20150623 header.b=BS4LWqS+; 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 c15si433386pgu.312.2018.03.19.21.08.37; Mon, 19 Mar 2018 21:08:52 -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; dkim=pass header.i=@endlessm-com.20150623.gappssmtp.com header.s=20150623 header.b=BS4LWqS+; 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 S1751680AbeCTEHq (ORCPT + 99 others); Tue, 20 Mar 2018 00:07:46 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:35490 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750968AbeCTEHn (ORCPT ); Tue, 20 Mar 2018 00:07:43 -0400 Received: by mail-pg0-f65.google.com with SMTP id d1so165110pgv.2 for ; Mon, 19 Mar 2018 21:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endlessm-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=68c/3p+sAYdTqA2qQx3+c8hXrfuiOPFZsM1LWEB3hMI=; b=BS4LWqS+wSLDI3uZdXVNCD3pQVToYEIXD72OLOE/QNO4Vpz4q5F6HdoBTMFUe/wU0S ONrMAeATSvGLZa3k+G9yY0UPuo2V/d4R1B5bskZVQ3EDO4yRooBU4CO55WFQYLrvpHvo nSClKXk8ZzhUlRuNFOzakrpn8e3VJvc6a1oVaktAQyHz0Na0/geee3m5MFMLa8eGGPjB g5ZFMKPxMNwJp9CU58I1f8jgxfcSX9wbi4845KYg1bcsl5582YiKV31KVVpfstxvDndz JN/yRyZmAPhLW7EI5yT0hBbDzMK37FKBn7gvdF+F4XxkYQyRAvcNc50B+lv27hSUEua5 Bvyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=68c/3p+sAYdTqA2qQx3+c8hXrfuiOPFZsM1LWEB3hMI=; b=bC6E53gKcpH4UVHyCRUHBjbB+VdRzo0xKg7rPpvYUzCj3AQhT4aIz72K2Ja264Q4bW ng6pmlt6K8C87UUpsOfMZB6JYVBagpA6Qb1WMJtR+Ahr6eNM25xZN008ClHKmO4Ta/IZ GsCrsCyaG6gUWhOliXKHIsdQK08qfKDwF208nGfNC+29IhcK3/sCPXWyywHbxjltxZZr hIPw6MwOAyxxPR24hZF0XuqaVytYSnx9801OP1+vVXrlSnd2ZvUV+HghZrIgHxwBaVoa GslopwSeLvApRcquzK0GD/vOCtP5I/61PO7EqTucyJyAQSos/bHmquYTlNYjwcY4mBFb PKqg== X-Gm-Message-State: AElRT7Es1P03Td0DvAsHyp0qQYVmgUJdW8n5Eu6sx3lzX6mey/envmXz MtF0br3K5pc7JtLO2rKcP3Zm0w== X-Received: by 10.99.170.5 with SMTP id e5mr10656376pgf.92.1521518862379; Mon, 19 Mar 2018 21:07:42 -0700 (PDT) Received: from limbo.local (125-227-158-176.HINET-IP.hinet.net. [125.227.158.176]) by smtp.gmail.com with ESMTPSA id g15sm763459pgv.61.2018.03.19.21.07.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 21:07:41 -0700 (PDT) From: Daniel Drake To: rjw@rjwysocki.net, lenb@kernel.org Cc: 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: [PATCH v2] ACPI / PM: allow deeper wakeup power states with no _SxD nor _SxW Date: Tue, 20 Mar 2018 12:07:35 +0800 Message-Id: <20180320040735.13025-1-drake@endlessm.com> X-Mailer: git-send-email 2.14.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. */ -- 2.14.1