From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Todd Poynor <tpoynor@mvista.com>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
Patrick Mochel <mochel@digitalimplant.org>,
linux-hotplug-devel@lists.sourceforge.net,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Hotplug for device power state changes
Date: Fri, 30 Apr 2004 00:50:26 +0000 [thread overview]
Message-ID: <1083286226.20473.159.camel@gaston> (raw)
In-Reply-To: <40918375.2090806@mvista.com>
> I figured system suspend/resume would need to be a separate event and
> isn't covered by this patch, which is for "runtime" individual device
> suspend/resume only. Also, the flood of notifications of all devices
> suspending/resuming might not be useful -- the single system
> suspend/resume event could imply these device events, although perhaps
> in some cases something would want to know exactly which devices were
> operable at system suspend time. I can also send a patch for system
> suspend/resume hotplug if there's interest.
>
> Now that you mention it, device power hotplug should be synchronous, to
> make sure the power management application has reacted to the changed
> state prior to the device going into actual service (in the case of a
> resume).
This is dangerous.
If the device you are suspending is on the VM path in any way,
beeing synchronous with a userland call can deadlock you solid.
This is even more true for system suspend where we are suspending
all devices including the main swap/storage.
There are various cases where I would have loved to get userland
more involved in the suspend/resume process for various reasons,
but in the end, I always got bitten by that problem. Userland cannot
be relied upon unless the process is made completely resident as soon
as we start the suspend dance.
More to this: If you use the "common" code in kernel/power, which I
don't (yet) use on pmac for suspend-to-ram, you'll also stop all
userland processes before notifying drivers (and suspend-to-disk
expects that).
Ben.
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_idÅ66&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Todd Poynor <tpoynor@mvista.com>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
Patrick Mochel <mochel@digitalimplant.org>,
linux-hotplug-devel@lists.sourceforge.net,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Hotplug for device power state changes
Date: Fri, 30 Apr 2004 10:50:26 +1000 [thread overview]
Message-ID: <1083286226.20473.159.camel@gaston> (raw)
In-Reply-To: <40918375.2090806@mvista.com>
> I figured system suspend/resume would need to be a separate event and
> isn't covered by this patch, which is for "runtime" individual device
> suspend/resume only. Also, the flood of notifications of all devices
> suspending/resuming might not be useful -- the single system
> suspend/resume event could imply these device events, although perhaps
> in some cases something would want to know exactly which devices were
> operable at system suspend time. I can also send a patch for system
> suspend/resume hotplug if there's interest.
>
> Now that you mention it, device power hotplug should be synchronous, to
> make sure the power management application has reacted to the changed
> state prior to the device going into actual service (in the case of a
> resume).
This is dangerous.
If the device you are suspending is on the VM path in any way,
beeing synchronous with a userland call can deadlock you solid.
This is even more true for system suspend where we are suspending
all devices including the main swap/storage.
There are various cases where I would have loved to get userland
more involved in the suspend/resume process for various reasons,
but in the end, I always got bitten by that problem. Userland cannot
be relied upon unless the process is made completely resident as soon
as we start the suspend dance.
More to this: If you use the "common" code in kernel/power, which I
don't (yet) use on pmac for suspend-to-ram, you'll also stop all
userland processes before notifying drivers (and suspend-to-disk
expects that).
Ben.
next prev parent reply other threads:[~2004-04-30 0:50 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-29 20:26 [PATCH] Hotplug for device power state changes Todd Poynor
2004-04-29 21:42 ` Russell King
2004-04-29 21:42 ` Russell King
2004-04-29 22:36 ` Todd Poynor
2004-04-29 22:36 ` Todd Poynor
2004-04-30 0:50 ` Benjamin Herrenschmidt [this message]
2004-04-30 0:50 ` Benjamin Herrenschmidt
2004-04-30 8:30 ` Russell King
2004-04-30 8:30 ` Russell King
2004-04-30 19:59 ` Todd Poynor
2004-04-30 19:59 ` Todd Poynor
2004-04-30 21:56 ` Greg KH
2004-04-30 21:56 ` Greg KH
2004-05-01 1:16 ` Todd Poynor
2004-05-01 1:16 ` Todd Poynor
2004-05-01 1:48 ` Greg KH
2004-05-01 1:48 ` Greg KH
2004-05-03 21:33 ` Todd Poynor
2004-05-03 21:33 ` Todd Poynor
2004-05-01 0:03 ` Nigel Cunningham
2004-05-01 0:03 ` Nigel Cunningham
2004-05-03 22:04 ` Todd Poynor
2004-05-03 22:04 ` Todd Poynor
2004-04-30 19:07 ` Todd Poynor
2004-04-30 19:07 ` Todd Poynor
2004-05-15 1:40 ` Nicolas Pitre
2004-05-15 1:40 ` Nicolas Pitre
2004-05-15 23:34 ` Pavel Machek
2004-05-15 23:34 ` Pavel Machek
2004-05-04 15:26 ` Patrick Mochel
2004-05-04 20:36 ` Todd Poynor
2004-05-04 20:36 ` Todd Poynor
2004-05-05 4:19 ` Patrick Mochel
2004-05-06 1:08 ` Todd Poynor
2004-05-06 1:08 ` Todd Poynor
2004-05-14 2:50 ` Pavel Machek
2004-05-14 2:50 ` Pavel Machek
2004-05-15 2:08 ` Todd Poynor
2004-05-15 2:08 ` Todd Poynor
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=1083286226.20473.159.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=linux-hotplug-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=tpoynor@mvista.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.