From: Greg KH <gregkh@suse.de>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>,
linux-pm@lists.linux-foundation.org, Pavel Machek <pavel@ucw.cz>,
Len Brown <len.brown@intel.com>,
"Jean Delvare (PC drivers core)" <khali@linux-fr.org>,
"Ben Dooks (embedded platforms)" <ben-linux@fluff.org>,
kyungmin.park@samsung.com, myungjoo.ham@gmail.com,
LKML <linux-kernel@vger.kernel.org>,
Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [RFC PATCH v2 1/3] PM / Core: suspend_again callback for device PM.
Date: Tue, 26 Apr 2011 06:17:37 -0700 [thread overview]
Message-ID: <20110426131737.GA13597@suse.de> (raw)
In-Reply-To: <201104261347.21811.rjw@sisk.pl>
On Tue, Apr 26, 2011 at 01:47:21PM +0200, Rafael J. Wysocki wrote:
> Moreover, I'm not sure if kernel subsystems (including drivers) should really
> decide when to generate wakeup signals in the first place. Generally,
> user space decides what devices should wake up the system from sleep and the
> kernel should follow. So, there shouldn't be any wakeup signals enabled
> beyond what user space has requested.
The RTC wakeup signals are ok though, right? Userspace is the one
asking for that from what I can tell.
> To conclude, I'm not sure about the approach. In particular, I'm not sure
> if the benefit is worth the effort and the resulting complications (ie. the
> possibility of having to deal with wakeup signals not requested by user
> space) seem to be a bit too far reaching.
>
> Greg, what do you think?
I agree with you in that I don't think that this type of feature is
valid at the moment.
I don't understand why our current situation doesn't work, what are we
lacking that is needed for these systems that we have not seen before?
What is the root problem that this is trying to solve?
thanks,
greg k-h
next prev parent reply other threads:[~2011-04-26 13:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-20 8:28 [RFC PATCH] PM / Core: suspend_again cb for syscore_ops MyungJoo Ham
2011-04-20 10:36 ` Pavel Machek
2011-04-20 20:28 ` Rafael J. Wysocki
2011-04-21 7:03 ` MyungJoo Ham
[not found] ` <1303781471-2477-1-git-send-email-myungjoo.ham@samsung.com>
2011-04-26 11:47 ` [RFC PATCH v2 1/3] PM / Core: suspend_again callback for device PM Rafael J. Wysocki
2011-04-26 13:17 ` Greg KH [this message]
2011-04-26 20:38 ` Pavel Machek
2011-04-26 20:49 ` Rafael J. Wysocki
2011-04-26 21:11 ` Pavel Machek
2011-04-26 21:36 ` Rafael J. Wysocki
2011-04-26 22:06 ` Pavel Machek
2011-04-26 20:57 ` Greg KH
2011-04-26 22:14 ` Pavel Machek
2011-04-26 20:35 ` Pavel Machek
2011-04-26 20:47 ` Rafael J. Wysocki
2011-04-26 21:06 ` Pavel Machek
2011-04-26 21:46 ` Rafael J. Wysocki
2011-04-26 22:10 ` Pavel Machek
2011-04-26 22:32 ` Rafael J. Wysocki
2011-04-27 6:36 ` MyungJoo Ham
2011-04-27 9:46 ` Stanislav Brabec
2011-04-27 10:47 ` MyungJoo Ham
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=20110426131737.GA13597@suse.de \
--to=gregkh@suse.de \
--cc=ben-linux@fluff.org \
--cc=khali@linux-fr.org \
--cc=kyungmin.park@samsung.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=myungjoo.ham@gmail.com \
--cc=myungjoo.ham@samsung.com \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=stern@rowland.harvard.edu \
/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).