linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).