From: Todd Poynor <tpoynor@mvista.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
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 19:07:06 +0000 [thread overview]
Message-ID: <4092A3DA.4040908@mvista.com> (raw)
In-Reply-To: <1083286226.20473.159.camel@gaston>
Benjamin Herrenschmidt wrote:
>>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.
Well, this feature is intended to allow power management of appropriate
devices; using sysfs or a driver call to individually suspend a device
required for proper system operation would be a danger, hotplug
notification or no. And the individual device notifications provided by
the patch under discussion are not for use during a system-wide
suspend/resume sequence. I would imagine system suspend/resume would be
separate events that probably would not notify of the individual device
suspends/resumes performed as a consequence. At any rate, yes, this
would occur outside of the code path that freezes processes and such.
--
Todd Poynor
MontaVista Software
-------------------------------------------------------
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: Todd Poynor <tpoynor@mvista.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
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 12:07:06 -0700 [thread overview]
Message-ID: <4092A3DA.4040908@mvista.com> (raw)
In-Reply-To: <1083286226.20473.159.camel@gaston>
Benjamin Herrenschmidt wrote:
>>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.
Well, this feature is intended to allow power management of appropriate
devices; using sysfs or a driver call to individually suspend a device
required for proper system operation would be a danger, hotplug
notification or no. And the individual device notifications provided by
the patch under discussion are not for use during a system-wide
suspend/resume sequence. I would imagine system suspend/resume would be
separate events that probably would not notify of the individual device
suspends/resumes performed as a consequence. At any rate, yes, this
would occur outside of the code path that freezes processes and such.
--
Todd Poynor
MontaVista Software
next prev parent reply other threads:[~2004-04-30 19:07 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
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 [this message]
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=4092A3DA.4040908@mvista.com \
--to=tpoynor@mvista.com \
--cc=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 \
/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.