Message-ID: <4092B02C.5090205@mvista.com>
Date: Fri, 30 Apr 2004 12:59:40 -0700
From: Todd Poynor <tpoynor@mvista.com>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040208)
MIME-Version: 1.0
To: Russell King <rmk+lkml@arm.linux.org.uk>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
       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
References: <20040429202654.GA9971@dhcp193.mvista.com> <20040429224243.L16407@flint.arm.linux.org.uk> <40918375.2090806@mvista.com> <1083286226.20473.159.camel@gaston> <20040430093012.A30928@flint.arm.linux.org.uk>
In-Reply-To: <20040430093012.A30928@flint.arm.linux.org.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2195
Lines: 51

Russell King wrote:

> And not being synchronous means that there's no point in calling
> userland, because userland won't run before the machine has
> suspended, so there's no point in calling it in the first place.
> Also consider the case where you suspend, and asynchronously queue
> up all these suspend scripts to run.  Then you resume and queue up
> the resume scripts to run.  What order do the suspend and resume
> scripts ultimately end up being run?
...
> Maybe we should have a two-pass approach, where the first pass
> synchronously tells userspace about the suspend, and the second
> pass does the actual suspend.  Then for resume the opposite.

I would argue that a system suspend/resume event does not need to also 
inform of the individual device suspend/resume events, since these can 
be implied.  But if we were to include individual device suspend/resume 
hotplug events as part of system suspend/resume then I would agree with 
a two-phase model, since notification at the time of actual hardware 
suspend does not work once something critical to userspace notification 
is shutdown.

So I'm planning to resubmit patches with the following:

* Individual device resume events signalled before, not after, the 
resume, so that userspace can react to any new requirements before the 
device is placed into service.

* Individual device suspend and resume events converted to synchronous 
events (that wait for hotplug processing to complete before continuing).

* Changes to kobject to allow kobject hotplug to optionally be 
synchronous if desired.  I'd assume this is a new hotplug_ops field.

* Synchronous hotplug events for system suspend and resume (without 
individual device notifications).  These events can probably be 
generated by the kobject hotplug methods by the existing power subsys 
(once the above enhancement is in place).

Any comments on this course of action welcomed.


-- 
Todd Poynor
MontaVista Software

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/