Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2732377imm; Sun, 3 Jun 2018 10:15:17 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJn7CvNN5CCOD+FQ7007f4wDeOtk7Z9uiX2Cl5OTfVVASo12a/uQLfoIIeuzqtZ0QXihmPt X-Received: by 2002:a17:902:321:: with SMTP id 30-v6mr18524727pld.122.1528046117683; Sun, 03 Jun 2018 10:15:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528046117; cv=none; d=google.com; s=arc-20160816; b=gXKkMZQxAPkFWHCvCbvE+EnUw247UU8ns7vAkf4pUTlPvuh6uZJ632X34VZ5TtmJHd DiX2jXSBn6xJEKcqsUqm3qkLOnki5LR5eP6pyayyysVLL449qY6+H+ghz17Nv10DlaQP 0orNGJbFWtJxLuZFwjI6BA2Dc5gCWfRIqyc0Djj9KIjgu/v52dGByhGYp9h0oiZEiY9Y 2mEnM5bmUCe1MNoBj5Z3UxI5zqmUMS0gUHIKWrRJsiZ7Hl8IoSHEb4sKnWA9Bt/I+QF+ Kb98VyO0IjY8DESP4DYJhuwQDD/MM3u8mUYh/ACfGMFNnzBphZGWmrP8NJcEsngPpT28 e24Q== 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=PDy27RvsPKSUvPMMk1fMsPK8dtS/LO1qFq0htqtPm2c=; b=sK3NSfVHDvzbV81/sDeSFw03hS6juDHxmjRu+Eb4mR97WwWUFkHh9PAzWJSCAIfTaX WvBH77zHFH3f3NaUI86dhhxX0K1yCpV1kEl3aA+/a239jRJBLLg+xChAAwTmBsra+d6y jlqRc1y1nexlakvuzHmvdmr4nz6cn/REV/nuOz9wvaMwPY/6xTH0aiiD/+1WDjAbNWi1 TWpRuh+zwGekzOgKzwroGwsUiwhwDj64jYbP1QVaZXt/z8yEocxwsMRLzRbTkvAZ/P9z F8G+YXZOLlgQjOJYVB1boGZtuAmJ2sgbr4GVjj0GTpA2yjcU1M7Ppq13RpbTTjbel2PM hnuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=uyJzYdBz; 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 a8-v6si43751135ple.222.2018.06.03.10.15.03; Sun, 03 Jun 2018 10:15:17 -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=uyJzYdBz; 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 S1751375AbeFCROc (ORCPT + 99 others); Sun, 3 Jun 2018 13:14:32 -0400 Received: from mail-vk0-f65.google.com ([209.85.213.65]:42671 "EHLO mail-vk0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750791AbeFCROb (ORCPT ); Sun, 3 Jun 2018 13:14:31 -0400 Received: by mail-vk0-f65.google.com with SMTP id s187-v6so6687794vke.9 for ; Sun, 03 Jun 2018 10:14:30 -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=PDy27RvsPKSUvPMMk1fMsPK8dtS/LO1qFq0htqtPm2c=; b=uyJzYdBzSuR+qnMMR6sIhaN0fe9SIx0A1IKLZftI7HXdgVpA9rFnvMtEvD36XSYP6h xCBvD3uUmoQWN2jSIV+BQLq/pBxBEvBdEA0gT+w14UXPcJJdDfHnD5Xmf/LYntVPFbKk JfKx2nGmFVxYSAP2Eyt0dwU/XL/VYvGLKHMDM2Bc/zd5VozlB5eWWraR/CEUnYXoqiOb eb+nKMDO+9pIvuDKJhMAY9Ps85bYo8LZEe69H8kWFdoQ7tfHrzLRaW/CTe7DTcXvo7hw MNLIUq7pG+mXtdGAZa6JthNld9N/iZ0G/zkjaP8oHgLCN0UR9mQAG74QXpjLM79iDeac qtag== 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=PDy27RvsPKSUvPMMk1fMsPK8dtS/LO1qFq0htqtPm2c=; b=rvfsCHLS366HvFt+qNzTqcMbXF6v8M+NXHPbNgBlYrukpiybQmSYV/ualVfcAkHfJi /Sz/pcZppvn9fMbCNYV439jGfISLmFjnJLf3h+7lcB0S3ehtes6YIePCWaOsppI2p4SW xKc37VCNx8oPF75PTENtX8fhKxL4QQ9O5xVYvxxd1Onu/H9hy+N7xp6aUSz4iryufzEi bnDT0CKZoCTPFiSKOrBSyfFLV5b7Sogv+HkE9oDb+aIgnuLQguiXZxkn2ES9qYPMxy0V s3xr/3EqV0MBaOZ56+DZFHvLtGS0nqqCmDrPnVGRceICwt3YZIpSZ/HsSvQFCYgu1xKC tIGw== X-Gm-Message-State: APt69E0ZurZD2QHja7hNruqFHidP41RUCwzAqt7bYRsWO/RyHcv174Eq 0yGv136+UJgii9Uqs8egHTiUPzseOH0qv5L4iK9khg== X-Received: by 2002:a1f:8a12:: with SMTP id m18-v6mr8496883vkd.84.1528046069679; Sun, 03 Jun 2018 10:14:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:1805:0:0:0:0:0 with HTTP; Sun, 3 Jun 2018 10:14:09 -0700 (PDT) In-Reply-To: References: <20180602023215.176521-1-ravisadineni@chromium.org> From: Ravi Chandra Sadineni Date: Sun, 3 Jun 2018 10:14:09 -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 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