All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.