From: Ravi Chandra Sadineni <ravisadineni@chromium.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
hpa@zytor.com, x86@kernel.org, rjw@rjwysocki.net, pavel@ucw.cz,
len.brown@intel.com, bhe@redhat.com, dyoung@redhat.com,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-pm@vger.kernel.org, Todd Broch <tbroch@chromium.org>
Subject: Re: [PATCH] power:sysfs: Expose device wakeup_event_count.
Date: Tue, 23 Jul 2019 09:43:55 -0700 [thread overview]
Message-ID: <CAEZbON6tukf5hTgpiNcUAQ5owf4KddHWFP5ubaeLU02Rmd-Zpw@mail.gmail.com> (raw)
In-Reply-To: <20190722182252.GA24412@kroah.com>
Hi Greg,
On Mon, Jul 22, 2019 at 11:22 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Jul 22, 2019 at 11:02:58AM -0700, Ravi Chandra Sadineni wrote:
> > Device level event_count can help user level daemon to track if a
> > praticular device has seen an wake interrupt during a suspend resume
> > cycle. Thus expose it via sysfs.
> >
> > Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>
> > ---
> > Documentation/ABI/testing/sysfs-devices-power | 11 ++++++++++
> > drivers/base/power/sysfs.c | 20 +++++++++++++++++++
> > 2 files changed, 31 insertions(+)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power
> > index 1ca04b4f0489..344549f4013f 100644
> > --- a/Documentation/ABI/testing/sysfs-devices-power
> > +++ b/Documentation/ABI/testing/sysfs-devices-power
> > @@ -89,6 +89,17 @@ Description:
> > attribute is not present. If the device is not enabled to wake
> > up the system from sleep states, this attribute is empty.
> >
> > +What: /sys/devices/.../power/wakeup_event_count
> > +Date: July 2019
> > +Contact: Ravi Chandra sadineni <ravisadineni@chromium.org>
> > +Description:
> > + The /sys/devices/.../wakeup_event_count attribute contains the
> > + number of signaled wakeup events associated with the device.
> > + This attribute is read-only. If the device is not capable to
> > + wake up the system from sleep states, this attribute is not
> > + present. If the device is not enabled to wake up the system
> > + from sleep states, this attribute is empty.
>
> The attribute is not "empty" it returns just an empty line.
Corrected the description.
>
> Is that really a good thing if you are expecting a number?
This is to adhere to the convention as described in
base/power/sysfs.c. Hope this is o.k
>
> > +
> > What: /sys/devices/.../power/wakeup_active_count
> > Date: September 2010
> > Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
> > diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
> > index f42044d9711c..8dc1235b9784 100644
> > --- a/drivers/base/power/sysfs.c
> > +++ b/drivers/base/power/sysfs.c
> > @@ -357,6 +357,25 @@ static ssize_t wakeup_count_show(struct device *dev,
> >
> > static DEVICE_ATTR_RO(wakeup_count);
> >
> > +static ssize_t wakeup_event_count_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + unsigned long count = 0;
> > + bool enabled = false;
> > +
> > + spin_lock_irq(&dev->power.lock);
> > + if (dev->power.wakeup) {
> > + count = dev->power.wakeup->event_count;
> > + enabled = true;
> > + }
> > + spin_unlock_irq(&dev->power.lock);
>
> Why do you need to lock? The state and count can change right after the
> lock, so what does this help with?
power.wakeup can be NULL (device_wakeup_detach ()) if wakeup is
disabled for a particular device.
>
> > + return enabled ? sprintf(buf, "%lu\n", count) : sprintf(buf, "\n");
>
> Use a real if statement please.
>
> > +}
> > +
> > +static DEVICE_ATTR_RO(wakeup_event_count);
> > +
> > +
> > +
>
> too many empty lines :)
Removed the empty lines.
>
> thanks,
>
> greg k-h
Thanks,
Ravi
prev parent reply other threads:[~2019-07-23 16:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-22 18:02 [PATCH] power:sysfs: Expose device wakeup_event_count Ravi Chandra Sadineni
2019-07-22 18:22 ` Greg KH
2019-07-23 16:43 ` Ravi Chandra Sadineni [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEZbON6tukf5hTgpiNcUAQ5owf4KddHWFP5ubaeLU02Rmd-Zpw@mail.gmail.com \
--to=ravisadineni@chromium.org \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=dyoung@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
--cc=tbroch@chromium.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).