Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6824382yba; Tue, 14 May 2019 14:29:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqzkYvXvWkyZwuQMwrpFXBnVqJpXkE++h6WeskJHwcrp1JkJv9rMhF2MJ1bCKbnIxjynBwg7 X-Received: by 2002:a63:5608:: with SMTP id k8mr40820522pgb.393.1557869363323; Tue, 14 May 2019 14:29:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557869363; cv=none; d=google.com; s=arc-20160816; b=fU5ftSX98gWrIgb98XrNzScyr4p0oaUpSFJTAFYPs971NMBnFbVKCXZ4bRpYN71e53 zi0KtLLCtlqKFJqFaTg6gFdSKWv0PFOrs2TgToOgudFwrO8aFocyXxSLICEkrR3EBHWD C7cjl921QKI4YX+UL7mjiSoUfrOV0fKfA/BW3xAWkJ9TjOLcLcB27Z9FR9FNjqIprots hYEEQWDuM4/KjtzjGZUjOnv5DRTf/ZxTF0dNY7KiWSaZIBwE8JQawIePZcHxtaKR8QKL xtNPGC2Rij1pXxubSQiNR0FEKmQ0pU97anhehjmiHWaK3YVgphTtOKglVDzYTn4OtpeS jmbg== 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; bh=fjF9WHDL8gGMrXzACRla3pDj/Q6/qqs0XNH+4oL9DEY=; b=HSTdHRnD54hEWcxKbFlMOy9NnLTdwBkBK/QfJq0UuJ3zvtq/XxtW/EeSKYyswtt6S9 tLNrpxuXttk+t+K8pACBdVwhMhtOGh/rRXO033M417kd0V/bHp5nT27j4u+uPpWz0Jd4 Qv/UptCPRcl7qGCxmXTrQEch6pvnX/RX+clNlSIlku93WKSbhkXNjkl2RIXgScxXWTss WOIgQ6ZCr53OZlxJ5DAJ4LiEDnQmyyLpNYALiwVubCNjaR+DXrvRk11Ler8/qfMzsxl2 ufkaS1q8+ECwE6P2bhU2bLoSoP9wTJOzEcAFq5fvx1hEI6ADvRJ0zxBj+kpG6CpCvyvC oUng== 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 j8si124520pfr.47.2019.05.14.14.29.08; Tue, 14 May 2019 14:29:23 -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 S1726569AbfENV2D (ORCPT + 99 others); Tue, 14 May 2019 17:28:03 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:60728 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726089AbfENV2D (ORCPT ); Tue, 14 May 2019 17:28:03 -0400 Received: from 79.184.255.148.ipv4.supernova.orange.pl (79.184.255.148) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.213) id 5516b80e513c2c6a; Tue, 14 May 2019 23:28:01 +0200 From: "Rafael J. Wysocki" To: Rajat Jain Cc: lenb@kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, rajatxjain@gmail.com, furquan@google.com Subject: Re: [RFC PATCH] ACPI: PM: Enable wake-up device GPEs for suspend-to-idle Date: Tue, 14 May 2019 23:28:00 +0200 Message-ID: <17514687.kF9exGCLEa@kreacher> In-Reply-To: <20190513191708.87956-1-rajatja@google.com> References: <20190513191708.87956-1-rajatja@google.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 Monday, May 13, 2019 9:17:08 PM CEST Rajat Jain wrote: > I noticed that recently multiple systems (chromebooks) couldn't wake > from S0ix using LID or Keyboard after updating to a newer kernel, I > bisected and the issue is seen starting the following commit: > > commit f941d3e41da7 ("ACPI: EC / PM: Disable non-wakeup GPEs for > suspend-to-idle") > > and found that the issue gets fixed if I revert it. I debugged and > found that although PNP0C0D:00 (representing the LID) is wake capable > and should wakeup the system per the code in acpi_wakeup_gpe_init() > and in drivers/acpi/button.c: > > localhost /sys # cat /proc/acpi/wakeup > Device S-state Status Sysfs node > LID0 S4 *enabled platform:PNP0C0D:00 > CREC S5 *disabled platform:GOOG0004:00 > *disabled platform:cros-ec-dev.1.auto > *disabled platform:cros-ec-accel.0 > *disabled platform:cros-ec-accel.1 > *disabled platform:cros-ec-gyro.0 > *disabled platform:cros-ec-ring.0 > *disabled platform:cros-usbpd-charger.2.auto > *disabled platform:cros-usbpd-logger.3.auto > D015 S3 *enabled i2c:i2c-ELAN0000:00 > PENH S3 *enabled platform:PRP0001:00 > XHCI S3 *enabled pci:0000:00:14.0 > GLAN S4 *disabled > WIFI S3 *disabled pci:0000:00:14.3 > localhost /sys # > > On debugging, I found that its corresponding GPE is not being enabled. > The particular GPE's "gpe_register_info->enable_for_wake" does not have any > bits set when acpi_enable_all_wakeup_gpes() comes around to use it. I > looked at code and could not find any other code path that should set the > bits in "enable_for_wake" bitmask for the wake enabled devices for s2idle > (I do see that it happens for S3 in acpi_sleep_prepare()). > > Thus I used the same call to enable the GPEs for wake enabled devices, > and verified that this fixes the regression I was seeing on multiple of > my devices. > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=203579 > Signed-off-by: Rajat Jain > --- > drivers/acpi/sleep.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c > index 403c4ff15349..e52f1238d2d6 100644 > --- a/drivers/acpi/sleep.c > +++ b/drivers/acpi/sleep.c > @@ -977,6 +977,8 @@ static int acpi_s2idle_prepare(void) > if (acpi_sci_irq_valid()) > enable_irq_wake(acpi_sci_irq); > > + acpi_enable_wakeup_devices(ACPI_STATE_S0); > + > /* Change the configuration of GPEs to avoid spurious wakeup. */ > acpi_enable_all_wakeup_gpes(); > acpi_os_wait_events_complete(); > @@ -1027,6 +1029,8 @@ static void acpi_s2idle_restore(void) > { > acpi_enable_all_runtime_gpes(); > > + acpi_disable_wakeup_devices(ACPI_STATE_S0); > + > if (acpi_sci_irq_valid()) > disable_irq_wake(acpi_sci_irq); > > Applied, thanks!