linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Todd Poynor <tpoynor@mvista.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: mochel@digitalimplant.org,
	linux-hotplug-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Hotplug for device power state changes
Date: Thu, 29 Apr 2004 22:36:37 +0000	[thread overview]
Message-ID: <40918375.2090806@mvista.com> (raw)
In-Reply-To: <20040429224243.L16407@flint.arm.linux.org.uk>

Russell King wrote:

> Note that we should run this synchronously with userspace - ie, wait
> for the userspace hotplug script to finish executing before moving
> on to the next device.  Why?
> 
> Think of the case where we're suspending the complete system.  If you
> go round and asynchonously try to run userspace scripts, chances are
> you'll have the CPU asleep before _any_ of the scripts have run, which
> means (eg) your DHCP client couldn't tell the server that its released
> its allocation.

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).

> Also, should we be telling userspace about suspend before we actually
> suspend the device?

I suppose that, depending on the reason notification is needed, "just 
before" or "just after" might be the right answer.  Now that you bring 
this up, it was originally my intention to notify of suspend "just 
after" (so power mgr can change power state, knowing that the associated 
device no longer has any requirements), and notify of resume "just 
before" (so power mgr can adjust power state to match requirements about 
to be put into service).  I'd be interested in hearing about other usage 
scenarios that might need a different notification order.  Thanks,

-- 
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

  reply	other threads:[~2004-04-29 22:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040429202654.GA9971@dhcp193.mvista.com>
2004-04-29 21:42 ` [PATCH] Hotplug for device power state changes Russell King
2004-04-29 22:36   ` Todd Poynor [this message]
2004-04-30  0:50     ` Benjamin Herrenschmidt
2004-04-30  8:30       ` Russell King
2004-04-30 19:59         ` Todd Poynor
2004-04-30 21:56           ` Greg KH
2004-05-01  1:16             ` Todd Poynor
2004-05-01  1:48               ` Greg KH
2004-05-03 21:33                 ` Todd Poynor
2004-05-01  0:03           ` Nigel Cunningham
2004-05-03 22:04             ` Todd Poynor
2004-04-30 19:07       ` Todd Poynor
2004-05-15  1:40   ` Nicolas Pitre
2004-05-15 23:34     ` Pavel Machek
     [not found] ` <Pine.LNX.4.50.0405040819490.3562-100000@monsoon.he.net>
2004-05-04 20:36   ` Todd Poynor
     [not found]     ` <Pine.LNX.4.50.0405042110440.30304-100000@monsoon.he.net>
2004-05-06  1:08       ` Todd Poynor
2004-05-14  2:50         ` Pavel Machek
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=40918375.2090806@mvista.com \
    --to=tpoynor@mvista.com \
    --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 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).