linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <swboyd@chromium.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Tri Vo <trong@android.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Hridya Valsaraju <hridya@google.com>,
	Sandeep Patil <sspatil@google.com>,
	Kalesh Singh <kaleshsingh@google.com>,
	Ravi Chandra Sadineni <ravisadineni@chromium.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	"Cc: Android Kernel" <kernel-team@android.com>,
	kbuild test robot <lkp@intel.com>
Subject: Re: [PATCH v5] PM / wakeup: show wakeup sources stats in sysfs
Date: Tue, 30 Jul 2019 16:41:38 -0700	[thread overview]
Message-ID: <5d40d5b3.1c69fb81.6047f.1cc3@mx.google.com> (raw)
In-Reply-To: <CAJZ5v0hj+e3+LZ+J1eOAT2REQne_J6aAXzkKVb0tJM4u9u--Rw@mail.gmail.com>

Quoting Rafael J. Wysocki (2019-07-30 16:05:55)
> On Wed, Jul 31, 2019 at 12:26 AM Stephen Boyd <swboyd@chromium.org> wrote:
> >
> > Quoting Rafael J. Wysocki (2019-07-30 15:17:55)
> > > On Tuesday, July 30, 2019 8:48:09 PM CEST Stephen Boyd wrote:
> > > >
> > > > Using the same prefix for the class and the device name is quite common.
> > > > For example, see the input, regulator, tty, tpm, remoteproc, hwmon,
> > > > extcon classes. I'd prefer it was left as /sys/class/wakeup/wakeupN. The
> > > > class name could be changed to wakeup_source perhaps (i.e.
> > > > /sys/class/wakeup_source/wakeupN)?
> > >
> > > Alternatively /sys/class/wakeup/wsN
> > >
> >
> > Or /sys/class/wakeup/eventN? It's your bikeshed to paint.
> 
> So actually the underlying problem here is that device_wakeup_enable()
> tries to register a wakeup source and then attach it to the device to
> avoid calling possibly sleeping functions under a spinlock.

Agreed, that is one problem.

> 
> However, it should be possible to call wakeup_source_create(name)
> first, then attach the wakeup source to the device (after checking for
> presence), and then invoke wakeup_source_add() (after dropping the
> lock).  If the wakeup source virtual device registration is done in
> wakeup_source_add(), that should avoid the problem altogether without
> having to introduce extra complexity.

While reordering the code to do what you describe will fix this specific
duplicate name problem, it won't fix the general problem with reusing
device names from one bus on a different bus/class. We can run into the
same problem when two buses name their devices the same name and then we
attempt to attach a wakeup source to those two devices. Or we can have a
problem where a virtual wakeup is made with the same name, and again
we'll try to make a duplicate named device. Using something like 'event'
or 'wakeup' or 'ws' as the prefix avoids this problem and keeps things
clean.

We should probably avoid letting the same virtual wakeup source be made
with the same name anyway, because userspace will be confused about what
virtual wakeup it is otherwise. I concede that using the name of the
wakeup source catches this problem without adding extra code.

Either way, I'd like to see what you outline implemented so that we
don't need to do more work than is necessary when userspace writes to
the file. I just don't want to see us need to change the name of the
wakeup device later on and then add a 'name' attribute to the class so
that we can avoid name collisions due to various buses controlling the
string we use to create the name of the wakeup device.


  parent reply	other threads:[~2019-07-30 23:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-30  2:43 [PATCH v5] PM / wakeup: show wakeup sources stats in sysfs Tri Vo
2019-07-30  5:46 ` Rafael J. Wysocki
2019-07-30 18:39   ` Tri Vo
2019-07-30 18:48     ` Stephen Boyd
2019-07-30 18:51       ` Greg Kroah-Hartman
2019-07-30 22:17       ` Rafael J. Wysocki
2019-07-30 22:26         ` Stephen Boyd
2019-07-30 23:05           ` Rafael J. Wysocki
2019-07-30 23:31             ` Tri Vo
2019-07-30 23:41             ` Stephen Boyd [this message]
2019-07-31  8:34               ` Rafael J. Wysocki
2019-07-31 11:58                 ` Rafael J. Wysocki
2019-07-31 17:13                   ` Stephen Boyd
2019-07-31 17:17                     ` Greg Kroah-Hartman
2019-07-31 21:19                     ` Rafael J. Wysocki
2019-07-31 21:23                       ` Tri Vo
2019-07-30 18:49     ` Greg Kroah-Hartman
2019-07-30  6:46 ` Greg KH
2019-07-30 19:20   ` Tri Vo

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=5d40d5b3.1c69fb81.6047f.1cc3@mx.google.com \
    --to=swboyd@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hridya@google.com \
    --cc=kaleshsingh@google.com \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=rafael@kernel.org \
    --cc=ravisadineni@chromium.org \
    --cc=rjw@rjwysocki.net \
    --cc=sspatil@google.com \
    --cc=trong@android.com \
    --cc=viresh.kumar@linaro.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).