Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2518378imm; Thu, 7 Jun 2018 12:01:38 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJ9g/R9Ve2AZWGkbAXEs6onPXefw2AeXZ6HvHq4FSV0boNV3H0Td42wSqA6fdd+YS+r0/YZ X-Received: by 2002:aa7:8386:: with SMTP id u6-v6mr2841954pfm.253.1528398098128; Thu, 07 Jun 2018 12:01:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528398098; cv=none; d=google.com; s=arc-20160816; b=e20Zklib0J8eDSRrdeBDEs021Far0meiSXxvLs45nY5yZMD2r7JrCuKgBRRac6BIKy xMmAuQyOLdPAEmij2zlbz2fkDjH1yIk5tZJvOLgd0zCBu8nnnytnf34BvPAwa92J0AU3 xXBHsFOIEdhx2yp9dOYa4PEKhRvnTTOva+N1AK6VdCvGrDYomO8uCiNV6IOlx0/8sL2E oepB0l/ejX1IuqrvQu8zxwbcXJgMO6fRgMonif04pgCQxJLNmQ9ALP8rFAYras3Wc1Qs wZI05eownLbbVXRfQA1AglQuUNEWnP/QQsewSnYSgUVvbxjDE0+crEO5pZPW0o0cpQbn IMdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=CBljQIfjBDSLVYosz1ncdDxJ0n7KLw23n6ER51QagWQ=; b=ZmSDyl1MTdZEfCZaH6uaGvLafi3mOBSVd0B8ul8Wo81NpAwK5Acg162fded0AYyZEv V8xghnXPXDhmAGyvWOSTaCm+yY7PkGs1tyF+BtIE19EIBF4SeR1gnSwSY8+Tt1CZpgdD PUEqtf9iTtoN5or9N1s6GF/TDRGAWyuHgvf2tpf2lYjzzpHUCMoYbhBF4c+t064dAfiD fyV/pH9JV6V56loh13gqJcf3GXmAVVWOH7o1qHjn80cVhEvOmVfarnJL3ZwA2MLPwhCS pg119kGese+r5AAeYaE4KFWnlYqbUg7/iNNumfzAyMbnhOZKfy3Kc/4it7IjkLhIulGP JG/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=VMhlszr2; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y187-v6si26343952pgb.120.2018.06.07.12.01.22; Thu, 07 Jun 2018 12:01:38 -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=@google.com header.s=20161025 header.b=VMhlszr2; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933627AbeFGQrw (ORCPT + 99 others); Thu, 7 Jun 2018 12:47:52 -0400 Received: from mail-ua0-f194.google.com ([209.85.217.194]:34498 "EHLO mail-ua0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932647AbeFGQrq (ORCPT ); Thu, 7 Jun 2018 12:47:46 -0400 Received: by mail-ua0-f194.google.com with SMTP id 74-v6so6975239uav.1 for ; Thu, 07 Jun 2018 09:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CBljQIfjBDSLVYosz1ncdDxJ0n7KLw23n6ER51QagWQ=; b=VMhlszr2mVF+JkVJR6W6aiQRSWURoEOCjBWcygx06DXl5c12qG+XF9J6bfEjI2W+4J 1E2bFKSIe683D/nXdoEOIs9qMus0ThJ6swOTw663/Q1pgoOD9sCGj+hnjLbIWf5O0v+H NYxzo8qzw24MxRk1388FUm++YdubleN7unhrv/3n6yPU8iEXQ8qcHr0rZ/Ir4Y1qiLs8 2yiXguzC4tBcZlEC2Mx7vLdUG1Drm0bCogEDhAlMn4wTd0JtQKVwUxo/B9YwQA6qyq1b Nb5PWfL7RA6tif4CXywm4cFRWRXYCyG2gJ/mB3UOLL9Xu/jvlEbzjqHqn6HpKiJa5bQU iRkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CBljQIfjBDSLVYosz1ncdDxJ0n7KLw23n6ER51QagWQ=; b=ex9YqUBOvyKkzTceiC7cRbx5CzhSLF5DAYF2jh9xvxJlVjINNvdnpK0fiRv4UfAu4s 4VXQL/XK4Wlts0MOUfDXEWORr8/JpLNXCkqVChT3PM96O/UHzRBpOP8a8H2cnTvZ8u9o cX8pObOEbkAwJ0avmqybxjdZWhqNFnrHf/vfLlmzxo0oZPz3Ar4BMPb03XkSfxMJSpWf fwiHorUSl8DsRLbb8PmpWCPu1P9MDZAQYQ1EypbOnjUrNMbwM4Hhqya90XHhnxJM9zQJ 2pchPfQMFeFavA6RdhG23p0gCug4OEquJtxBLBx93Kj8eo9EnBEEORGD0VNmC+KfpeNB /UEA== X-Gm-Message-State: APt69E3Tie8Iul9v2oxpqcryU2l/XF1FYSPr48Rb5ZpzDe/N5zPgEzMv 6GO/BVv7YizcUP0d2sQ3EqEZWT5+Jods996VVLbB2w== X-Received: by 2002:ab0:1251:: with SMTP id s17-v6mr1636177uac.37.1528390064650; Thu, 07 Jun 2018 09:47:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:80d4:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 09:47:24 -0700 (PDT) In-Reply-To: References: <20180602023215.176521-1-ravisadineni@chromium.org> From: Ravi Chandra Sadineni Date: Thu, 7 Jun 2018 09:47:24 -0700 Message-ID: Subject: Re: [PATCH] power: Print wakeup_count instead of event_count in the sysfs attribute. To: "Rafael J. Wysocki" Cc: Ravi Chandra Sadineni , "Rafael J. Wysocki" , chenhong3@huawei.com, Pavel Machek , Dmitry Torokhov , Len Brown , Greg Kroah-Hartman , Todd Broch , Linux Kernel Mailing List , Linux PM , Rajat Jain , Benson Leung Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rafeal, Soft ping. Is this patch good to be merged ? Thanks, Ravi On Sun, Jun 3, 2018 at 10:14 AM, Ravi Chandra Sadineni wrote: > Hi Rafael, > > On Sun, Jun 3, 2018 at 1:05 AM, Rafael J. Wysocki wrote: >> On Sat, Jun 2, 2018 at 4:32 AM, Ravi Chandra Sadineni >> wrote: >>> Currently we show event_count instead of wakeup_count as part of per >>> device wakeup_count sysfs attribute. Change it to wakeup_count to make >>> it more meaningful. >> >> More information, please. >> >> In particular, why it is more meaningful. > Wakeup_count increments only when events_check_enabled is set. This > bool is set whenever we write current wakeup count to > /sys/power/wakeup_count from the user land. Also events_check_enabled > is cleared on every resume. My understanding is that, userland is > expected to write to this just before suspend. This way > pm_wakeup_event() when called from irqs will increment the > wakeup_count only if we are in system wide suspend resume cycle and > should give a fair approximation of how many times a device might have > caused a wake from S3/S0iX. event_count on the other hand will > increment every time pm_wakeup_event() is called irrespective of > whether we are in a suspend/resume cycle. For example when I try > doing something like this (https://lkml.org/lkml/2018/6/1/890), we see > the wakeup_count sysfs attribute for the particular device > incrementing every time there is a irq. If it is important to expose > event_count via sysfs attribute, should we create another attribute ? > Also we do expose each of these counters via > debugfs(/sys/kernel/debug/wake_sources). > > Please correct me if I am wrong or missing something. Also if there is > a better way to do this, please let me know. >> >> Thanks, >> Rafael