All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Qian Cai <cai@lca.pw>, Tri Vo <trong@android.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	rafael@kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: "PM / wakeup: Show wakeup sources stats in sysfs" causes boot warnings
Date: Wed, 14 Aug 2019 01:40:14 -0700	[thread overview]
Message-ID: <20190814084014.GB52127@atomide.com> (raw)
In-Reply-To: <5d53b238.1c69fb81.d3cd3.cd53@mx.google.com>

* Stephen Boyd <swboyd@chromium.org> [691231 23:00]:
> I also notice that device_set_wakeup_capable() has a check to see if the
> device is registered yet and it skips creating sysfs entries for the
> device if it isn't created in sysfs yet. Why? Just so it can be called
> before the device is created? I guess the same logic is handled by
> dpm_sysfs_add() if the device is registered after calling
> device_set_wakeup_*().

Hmm just guessing.. It's maybe because drivers can enable and disable
the wakeup capability at any point for example like driver/net drivers
do based on WOL etc?

> There's two approaches I see:
> 
> 	1) Do a similar check for device_set_wakeup_enable() and skip
> 	adding the wakeup class until dpm_sysfs_add().
> 
> 	2) Find each case where this happens and only call wakeup APIs
> 	on the device after the device is added.
> 
> I guess it's better to let devices have wakeup modified on them before
> they're registered with the device core?

I think we should at least initially handle case #1 above as multiple
places otherwise seem to break. Then maybe we could add a warning to
help fix all the #2 cases if needed?

Regards,

Tony

  reply	other threads:[~2019-08-14  8:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-13 21:32 "PM / wakeup: Show wakeup sources stats in sysfs" causes boot warnings Qian Cai
2019-08-13 22:35 ` Stephen Boyd
2019-08-13 23:04   ` Tri Vo
2019-08-13 23:10     ` Rafael J. Wysocki
2019-08-14 13:18   ` Qian Cai
2019-08-14  0:35 ` Stephen Boyd
2019-08-14  7:03 ` Stephen Boyd
2019-08-14  8:40   ` Tony Lindgren [this message]
2019-08-14 18:37     ` Tri Vo
2019-08-16 12:17       ` Rafael J. Wysocki
2019-08-16 14:19         ` Stephen Boyd
2019-08-19  9:33           ` Rafael J. Wysocki
2019-08-14 15:19   ` Dmitry Torokhov

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=20190814084014.GB52127@atomide.com \
    --to=tony@atomide.com \
    --cc=cai@lca.pw \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=swboyd@chromium.org \
    --cc=trong@android.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.