From mboxrd@z Thu Jan 1 00:00:00 1970 From: Todd Poynor Date: Sat, 01 May 2004 01:16:22 +0000 Subject: Re: [PATCH] Hotplug for device power state changes Message-Id: <4092FA66.20704@mvista.com> List-Id: 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> <4092B02C.5090205@mvista.com> <20040430215621.GA14015@kroah.com> In-Reply-To: <20040430215621.GA14015@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset="macroman" Content-Transfer-Encoding: base64 To: Greg KH Cc: Russell King , Benjamin Herrenschmidt , Patrick Mochel , linux-hotplug-devel@lists.sourceforge.net, Linux Kernel list R3JlZyBLSCB3cm90ZToKPiBPbiBGcmksIEFwciAzMCwgMjAwNCBhdCAxMjo1OTo0MFBNIC0wNzAw LCBUb2RkIFBveW5vciB3cm90ZToKPiAKPj4qIENoYW5nZXMgdG8ga29iamVjdCB0byBhbGxvdyBr b2JqZWN0IGhvdHBsdWcgdG8gb3B0aW9uYWxseSBiZSAKPj5zeW5jaHJvbm91cyBpZiBkZXNpcmVk LiAgSSdkIGFzc3VtZSB0aGlzIGlzIGEgbmV3IGhvdHBsdWdfb3BzIGZpZWxkLgo+IAo+IAo+IElj ay4KCklzIHRoZSBvYmplY3Rpb24gdG8gdXNpbmcga29iamVjdCBmb3Igc3luY2hyb25vdXMgaG90 cGx1ZyBldmVudHMsIG9yIHRvIAp1c2luZyBhIGhvdHBsdWdfb3BzIGZsYWcgdG8gaW5kaWNhdGUg d2hpY2gga2luZCBpcyBuZWVkZWQ/ICBXb3VsZCB0aGUgCmFkZGl0aW9uIG9mIGEga29iamVjdF9o b3RwbHVnX3N5bmMgZnVuY3Rpb24gYmUgYmV0dGVyPyAgT3IgYSAKaGFuZHNoYWtlLWxpa2UgaW50 ZXJmYWNlIGFzIHdpdGggZmlybXdhcmUgZG93bmxvYWRzPwoKPj4qIFN5bmNocm9ub3VzIGhvdHBs dWcgZXZlbnRzIGZvciBzeXN0ZW0gc3VzcGVuZCBhbmQgcmVzdW1lICh3aXRob3V0IAo+PmluZGl2 aWR1YWwgZGV2aWNlIG5vdGlmaWNhdGlvbnMpLiAgVGhlc2UgZXZlbnRzIGNhbiBwcm9iYWJseSBi ZSAKPj5nZW5lcmF0ZWQgYnkgdGhlIGtvYmplY3QgaG90cGx1ZyBtZXRob2RzIGJ5IHRoZSBleGlz dGluZyBwb3dlciBzdWJzeXMgCj4+KG9uY2UgdGhlIGFib3ZlIGVuaGFuY2VtZW50IGlzIGluIHBs YWNlKS4KPiAKPiAKPiBCdXQgd2h5PyAgRG8geW91IHJlYWxseSBuZWVkIHRoaXM/ICBIYXZlIHlv dSBhY3R1YWxseSB0ZXN0ZWQgYSBzeXN0ZW0gdG8KPiBzZWUgaWYgaXQgaXMgbmVlZGVkPwoKVGhp cyBpcyBzb21ldGhpbmcgdGhhdCB3YXMgcmVxdWVzdGVkIG9mIG1lIGJ5IG90aGVycyB3aG8gYnVp bGQgTGludXggCmludG8gY29uc3VtZXIgZWxlY3Ryb25pY3MgZGV2aWNlcy4gIFBlcmhhcHMgc29t ZSBvZiB0aGUgaW50ZXJlc3RlZCAKcGFydGllcyBtYXkgc3BlYWsgdXAgaGVyZSB0byBhZGQgbW9y ZSBpbnNpZ2h0LiAgQW1vbmcgdGhlIGludGVuZGVkIHVzZXMgCnRoYXQgSSdtIGF3YXJlIG9mIGFy ZTogc2F2aW5nIGFwcGxpY2F0aW9uIHN0YXRlIHRvIHN0YWJsZSBzdG9yYWdlIChmb3IgCmV4YW1w bGUsIHRvIGJlIHByZXBhcmVkIGluIGNhc2UgdGhlIGJhdHRlcnkgZGllcyBkdXJpbmcgYW4gZXh0 ZW5kZWQgCiJzdXNwZW5kZWQiIHBlcmlvZCwgYW5kIHN1Y2ggZ2FkZ2V0cyBvZnRlbiBkbyBub3Qg aGF2ZSBhIGRldmljZSBzdWl0YWJsZSAKZm9yIGEgY29tcGxldGUgc3lzdGVtIHN1c3BlbmQtdG8t ZGlzayksIHRlcm1pbmF0aW5nIGFwcGxpY2F0aW9ucyB0aGF0IApyZXNpZGUgaW4gbWVtb3J5IGJh bmtzIHRvIGJlIHBvd2VyZWQgb2ZmIGR1cmluZyB0aGUgc3VzcGVuZCAodGhpcyBhbHNvIApyZWxp ZXMgb24gb3RoZXIgZW5oYW5jZW1lbnRzIHRvIGFsbG9jYXRlIG1lbW9yeSBhY2NvcmRpbmdseSks IGFuZCAKZHJvcHBpbmcgbmV0d29yayBjb25uZWN0aW9ucyBpbiBvcmRlciB0byBjb25zZXJ2ZSBy ZXNvdXJjZXMgb24gc2VydmVycyAKdGhhdCBzdXBwb3J0IG1vYmlsZSBkZXZpY2VzLiAgSXQgc291 bmRzIGxpa2UgdGhlIGZvbGtzIHRoYXQgZGVhbCB3aXRoIApBQ1BJIHBvd2VyIG1hbmFnZW1lbnQg aGF2ZSBmb3VuZCB1c2UgZm9yIHN1Y2ggYSBtZWNoYW5pc20gaW4gdGhlIApzZXJ2ZXIvZGVza3Rv cCB3b3JsZCBhcyB3ZWxsLgoKVGhhbmtzLAoKLS0gClRvZGQgUG95bm9yCk1vbnRhVmlzdGEgU29m dHdhcmUKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQpUaGlzIFNGLk5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IE9yYWNsZSAxMGcKR2V0 IGNlcnRpZmllZCBvbiB0aGUgaG90dGVzdCB0aGluZyBldmVyIHRvIGhpdCB0aGUgbWFya2V0Li4u IE9yYWNsZSAxMGcuIApUYWtlIGFuIE9yYWNsZSAxMGcgY2xhc3Mgbm93LCBhbmQgd2UnbGwgZ2l2 ZSB5b3UgdGhlIGV4YW0gRlJFRS4gCmh0dHA6Ly9hZHMub3Nkbi5jb20vP2FkX2lkMTQ5JmFsbG9j X2lkgTY2Jm9wPWNsaWNrCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCkxpbnV4LWhvdHBsdWctZGV2ZWwgbWFpbGluZyBsaXN0ICBodHRwOi8vbGludXgtaG90 cGx1Zy5zb3VyY2Vmb3JnZS5uZXQKTGludXgtaG90cGx1Zy1kZXZlbEBsaXN0cy5zb3VyY2Vmb3Jn ZS5uZXQKaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vbGludXgt aG90cGx1Zy1kZXZlbA== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261891AbUEABQi (ORCPT ); Fri, 30 Apr 2004 21:16:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261897AbUEABQi (ORCPT ); Fri, 30 Apr 2004 21:16:38 -0400 Received: from gateway-1237.mvista.com ([12.44.186.158]:61166 "EHLO av.mvista.com") by vger.kernel.org with ESMTP id S261891AbUEABQg (ORCPT ); Fri, 30 Apr 2004 21:16:36 -0400 Message-ID: <4092FA66.20704@mvista.com> Date: Fri, 30 Apr 2004 18:16:22 -0700 From: Todd Poynor User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg KH CC: Russell King , Benjamin Herrenschmidt , Patrick Mochel , linux-hotplug-devel@lists.sourceforge.net, Linux Kernel list 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> <4092B02C.5090205@mvista.com> <20040430215621.GA14015@kroah.com> In-Reply-To: <20040430215621.GA14015@kroah.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Greg KH wrote: > On Fri, Apr 30, 2004 at 12:59:40PM -0700, Todd Poynor wrote: > >>* Changes to kobject to allow kobject hotplug to optionally be >>synchronous if desired. I'd assume this is a new hotplug_ops field. > > > Ick. Is the objection to using kobject for synchronous hotplug events, or to using a hotplug_ops flag to indicate which kind is needed? Would the addition of a kobject_hotplug_sync function be better? Or a handshake-like interface as with firmware downloads? >>* 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). > > > But why? Do you really need this? Have you actually tested a system to > see if it is needed? This is something that was requested of me by others who build Linux into consumer electronics devices. Perhaps some of the interested parties may speak up here to add more insight. Among the intended uses that I'm aware of are: saving application state to stable storage (for example, to be prepared in case the battery dies during an extended "suspended" period, and such gadgets often do not have a device suitable for a complete system suspend-to-disk), terminating applications that reside in memory banks to be powered off during the suspend (this also relies on other enhancements to allocate memory accordingly), and dropping network connections in order to conserve resources on servers that support mobile devices. It sounds like the folks that deal with ACPI power management have found use for such a mechanism in the server/desktop world as well. Thanks, -- Todd Poynor MontaVista Software