From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Greg KH <greg@kroah.com>,
pm list <linux-pm@lists.linux-foundation.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Alan Stern <stern@rowland.harvard.edu>,
Len Brown <lenb@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Alexey Starikovskiy <astarikovskiy@suse.de>,
David Brownell <david-b@pacbell.net>, Pavel Machek <pavel@ucw.cz>,
Oliver Neukum <oliver@neukum.org>,
Nigel Cunningham <ncunningham@crca.org.au>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/3] PM: Introduce new top level suspend and hibernation callbacks (rev. 8)
Date: Mon, 14 Apr 2008 10:46:57 +1000 [thread overview]
Message-ID: <1208134017.6958.94.camel@pasglop> (raw)
In-Reply-To: <200804140231.32245.rjw@sisk.pl>
On Mon, 2008-04-14 at 02:31 +0200, Rafael J. Wysocki wrote:
>
> Well, in our discussions with Alan Stern ->prepare() turned out to be necessary
> for exactly one reason, preventing new children of the device from being
> registered (by threads concurrent wrt the suspend thread). For this reason,
> it doesn't really seem a good idea to run it before the freezer (seemingly, it
> would be difficult to avoid situations in which the freezer would fail as a
> result of ->prepare()).
I'm opposed to designing something around the freezer since we know it
will ultimately go away.
If things like USB have issues with userland doing nasty things after
prepare(), then those things need to be fixed. The freezer will only
hide bugs and not even always or properly and not on all archs.
> It looks like you'd like to have a third callback executed before the freezer,
> but OTOH I don't see the reason not to use a notifier for such things.
That's just gratuituous complication imho. We can add callbacks every
week and no driver will every find out what to use and when.
prepare() has quite well defined and nice semantics if you ignore your
freezer trickery. It matches well with the needs of things like
request_firmware or the DRM, and possibly a few others, in addition to
matching well the need to block bus discovery.
If some drivers have issue because of what userland might do after
prepare(), then those drivers need to be fixed. We all know the freezer
is not a proper solution. It just hides problems and not always
correctly.
> I have imagined that while we have the freezer, the operations that need to
> be carried out with the user space available will be done using notifiers
> and the rest will be done by ->prepare() and ->suspend(). Next, when we
> finally drop the freezer, it will be possible to move the code from the
> notifiers into ->prepare() and drop the notifiers altogether.
Why do this two steps ? What is the point ?
> Since, as you said, there aren't too many drivers that will need anything like
> that, it seems perfectly doable to me.
Ben.
next prev parent reply other threads:[~2008-04-14 0:48 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-03 23:11 [PATCH 0/3] PM: New suspend and hibernation callbacks Rafael J. Wysocki
2008-04-03 23:12 ` [PATCH 1/3] PM: Introduce new top level suspend and hibernation callbacks (rev. 7) Rafael J. Wysocki
2008-04-12 0:23 ` Greg KH
2008-04-13 13:31 ` Rafael J. Wysocki
2008-04-13 13:33 ` [PATCH 1/3] PM: Introduce new top level suspend and hibernation callbacks (rev. 8) Rafael J. Wysocki
2008-04-13 21:05 ` Benjamin Herrenschmidt
2008-04-13 21:39 ` Rafael J. Wysocki
2008-04-13 22:10 ` Benjamin Herrenschmidt
2008-04-13 22:27 ` Rafael J. Wysocki
2008-04-13 22:47 ` Benjamin Herrenschmidt
2008-04-13 23:08 ` Rafael J. Wysocki
2008-04-13 23:46 ` Benjamin Herrenschmidt
2008-04-14 0:31 ` Rafael J. Wysocki
2008-04-14 0:46 ` Benjamin Herrenschmidt [this message]
2008-04-14 1:09 ` Rafael J. Wysocki
2008-04-14 3:23 ` Benjamin Herrenschmidt
2008-04-14 6:43 ` Oliver Neukum
2008-04-14 7:23 ` Benjamin Herrenschmidt
2008-04-14 7:37 ` Oliver Neukum
2008-04-14 7:50 ` Benjamin Herrenschmidt
2008-04-14 12:11 ` Rafael J. Wysocki
2008-04-14 15:13 ` Alan Stern
2008-04-14 20:48 ` Benjamin Herrenschmidt
2008-04-14 14:49 ` Alan Stern
2008-04-14 20:41 ` Oliver Neukum
2008-04-14 1:37 ` Nigel Cunningham
2008-04-14 12:25 ` Rafael J. Wysocki
2008-04-13 23:11 ` Nigel Cunningham
2008-04-13 23:17 ` Rafael J. Wysocki
2008-04-13 23:29 ` Nigel Cunningham
2008-04-13 23:23 ` Alan Stern
2008-04-13 23:33 ` Rafael J. Wysocki
2008-04-13 23:49 ` Benjamin Herrenschmidt
2008-04-13 23:48 ` Benjamin Herrenschmidt
2008-04-14 0:07 ` Rafael J. Wysocki
2008-04-14 0:40 ` Benjamin Herrenschmidt
2008-04-14 0:59 ` Rafael J. Wysocki
2008-04-14 0:43 ` Benjamin Herrenschmidt
2008-04-14 0:50 ` Rafael J. Wysocki
2008-04-14 4:47 ` David Brownell
2008-04-14 12:34 ` Rafael J. Wysocki
2008-04-14 14:51 ` Alan Stern
2008-04-14 20:47 ` Benjamin Herrenschmidt
2008-04-14 21:21 ` Pavel Machek
2008-04-14 10:55 ` Pavel Machek
2008-04-14 20:45 ` Benjamin Herrenschmidt
2008-04-14 20:56 ` Rafael J. Wysocki
2008-04-15 19:27 ` patch pm-introduce-new-top-level-suspend-and-hibernation-callbacks.patch added to gregkh-2.6 tree gregkh
2008-04-13 13:33 ` [PATCH 2/3] PM: New suspend and hibernation callbacks for platform bus type (rev. 3) Rafael J. Wysocki
2008-04-15 19:27 ` patch pm-new-suspend-and-hibernation-callbacks-for-platform-bus-type.patch added to gregkh-2.6 tree gregkh
2008-04-13 13:34 ` [PATCH 3/3] PM: New suspend and hibernation callbacks for PCI bus type (rev. 4) Rafael J. Wysocki
2008-04-15 19:27 ` patch pm-new-suspend-and-hibernation-callbacks-for-pci-bus-type.patch added to gregkh-2.6 tree gregkh
2008-04-29 22:26 ` PM: New suspend and hibernation callbacks for PCI bus type Greg KH
2008-04-30 12:09 ` Rafael J. Wysocki
2008-05-07 5:08 ` patch pm-new-suspend-and-hibernation-callbacks-for-pci-bus-type.patch added to gregkh-2.6 tree gregkh
2008-04-03 23:13 ` [PATCH 2/3] PM: New suspend and hibernation callbacks for platform bus type (rev. 3) Rafael J. Wysocki
2008-04-03 23:15 ` [PATCH 3/3] PM: New suspend and hibernation callbacks for PCI " Rafael J. Wysocki
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=1208134017.6958.94.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=akpm@linux-foundation.org \
--cc=astarikovskiy@suse.de \
--cc=david-b@pacbell.net \
--cc=greg@kroah.com \
--cc=jbarnes@virtuousgeek.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=ncunningham@crca.org.au \
--cc=oliver@neukum.org \
--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).