Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp4922856imm; Tue, 26 Jun 2018 02:57:28 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJ1aevQvI2SkjoKA52S/GeifVYxdPPT0aVozdY3M9qbW8XBAcmMNeuNStZPE400sC57jpn/ X-Received: by 2002:a65:6211:: with SMTP id d17-v6mr773956pgv.450.1530007048679; Tue, 26 Jun 2018 02:57:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530007048; cv=none; d=google.com; s=arc-20160816; b=YlI+CmCcnDtuFRXByGCbNPdie7kgfMlPKFn7RPd2U/sWmdppWZtr+nPbZgSKdTfvXy g9cF1d3bAMsB2p0dutnZzAP4zf06Oyvk9Q6ueJlAlDRDwk21x3iMk8g8RxOng4cYewvy 002KTIaLJEHg5ld4I9TqNhoZBAx3xIEuax6EcU4nSdd3Gclob9t+/Rwpk5N9D637qldT pwcxZacMDuvPLBozqeEXA5LRBLXvMYFl6Xw7VdPkUb2YTOW5dmNrFXxgSTEFBwrgORSM 72OJ3zM7DELsGeUcZxUrgsVpAO+zypomP/0wXmMffnmYnZ5AKDC7Prgfd/Mm4XhxIyRq UWMg== 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=yEdGK1pB4r1J1dkg9TaBoqimSTc87T+KFiGnmTUJR+g=; b=mvZZqITIo4aC40pMJe/I+vxLYngTVxj2c3JD5+V2MnM9Yp0V4EG6bDurqTBtxqDa/c hw+AYLFh201m6jvB1c+QuOdM3Cg5dppLO+9SsZGtQxWizVXxrDOyeq9xaasrJShFxxJZ LaQTw7uqi0m4AL4w/f2mCXa0n1tvNsigZzISL2xcruL8ndi9+uA6/fLabnKukdCOgUyb QCce4LvfVxVc6Mfs1PPkGIHoJz7BQGlUT4KcXsaYNg21oYuQ0liuK5p36MLMbUIq+4t1 j3zN8ovm5KGWcuwywLDIzaj8MFgO98GVd0UO6RShz/kIG/VtonwVFhJg0FS/RH5CgIRS t3Kw== 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 g26-v6si1274046pfe.4.2018.06.26.02.57.13; Tue, 26 Jun 2018 02:57:28 -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 S1752978AbeFZJ4e (ORCPT + 99 others); Tue, 26 Jun 2018 05:56:34 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:55250 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752606AbeFZJ4d (ORCPT ); Tue, 26 Jun 2018 05:56:33 -0400 Received: from 79.184.255.183.ipv4.supernova.orange.pl (79.184.255.183) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83) id 95538d121b07fdc1; Tue, 26 Jun 2018 11:56:31 +0200 From: "Rafael J. Wysocki" To: Ravi Chandra Sadineni Cc: lenb@kernel.org, ravisadineni@google.com, dmitry.torokhov@gmail.com, tbroch@google.com, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, rajatja@google.com, bleung@google.com, furquan@chromium.org Subject: Re: [PATCH V2] ACPI LID: increment wakeup count only when notified. Date: Tue, 26 Jun 2018 11:55:15 +0200 Message-ID: <2352530.ePvj7nqZEq@aspire.rjw.lan> In-Reply-To: <20180611175759.181681-1-ravisadineni@chromium.org> References: <20180611175759.181681-1-ravisadineni@chromium.org> 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, June 11, 2018 7:57:59 PM CEST Ravi Chandra Sadineni wrote: > Currently ACPI LID increments wakeup count irrespective of the wake source. What exactly does the above mean? > This is because we call acpi_lid_initialize_state on every resume. I guess "because acpi_lid_initialize_state() is called on every system resume and it triggers acpi_lid_notify_state() which invokes acpi_pm_wakeup_event() for the lid device, the lid's wakeup count is incremented even if the lid was not the source of the event that woke up the system", right? > Userland deamons using wakeup_count to identify the potential wake > source for the last wake will be thrown off by this. Something like: "That behavior confuses user space deamons using wakeup_count to identify the potential system wakeup source." > Instead increment > the wakeup count only when there is a FIXED_HARDWARE/NOTFIY_STATUS event. So "to avoid that confusion, only trigger acpi_pm_wakeup_event() in the acpi_button_notify() path and don't do that in the acpi_lid_initialize_state() path." > Signed-off-by: Ravi Chandra Sadineni > --- > V2: Increment the wakeup count only when the lid is open. > > drivers/acpi/button.c | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c > index 2345a5ee2dbbc..d2fe03e4faf05 100644 > --- a/drivers/acpi/button.c > +++ b/drivers/acpi/button.c > @@ -235,9 +235,6 @@ static int acpi_lid_notify_state(struct acpi_device *device, int state) > button->last_time = ktime_get(); > } > > - if (state) > - acpi_pm_wakeup_event(&device->dev); > - > ret = blocking_notifier_call_chain(&acpi_lid_notifier, state, device); > if (ret == NOTIFY_DONE) > ret = blocking_notifier_call_chain(&acpi_lid_notifier, state, > @@ -366,7 +363,8 @@ int acpi_lid_open(void) > } > EXPORT_SYMBOL(acpi_lid_open); > > -static int acpi_lid_update_state(struct acpi_device *device) > +static int acpi_lid_update_state(struct acpi_device *device, > + bool is_notification) Please rename "is_notification" to "signal_wakeup" or similar. > { > int state; > > @@ -374,6 +372,9 @@ static int acpi_lid_update_state(struct acpi_device *device) > if (state < 0) > return state; > > + if (state && is_notification) > + acpi_pm_wakeup_event(&device->dev); > + > return acpi_lid_notify_state(device, state); > } > > @@ -384,7 +385,7 @@ static void acpi_lid_initialize_state(struct acpi_device *device) > (void)acpi_lid_notify_state(device, 1); > break; > case ACPI_BUTTON_LID_INIT_METHOD: > - (void)acpi_lid_update_state(device); > + (void)acpi_lid_update_state(device, false); > break; > case ACPI_BUTTON_LID_INIT_IGNORE: > default: > @@ -409,7 +410,7 @@ static void acpi_button_notify(struct acpi_device *device, u32 event) > users = button->input->users; > mutex_unlock(&button->input->mutex); > if (users) > - acpi_lid_update_state(device); > + acpi_lid_update_state(device, true); > } else { > int keycode; > >