From mboxrd@z Thu Jan 1 00:00:00 1970 From: Todd Poynor Date: Tue, 04 May 2004 20:36:40 +0000 Subject: Re: [PATCH] Hotplug for device power state changes Message-Id: <4097FED8.3020003@mvista.com> List-Id: References: <20040429202654.GA9971@dhcp193.mvista.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="macroman" Content-Transfer-Encoding: base64 To: Patrick Mochel Cc: linux-hotplug-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org UGF0cmljayBNb2NoZWwgd3JvdGU6Cj4+QSBwYXRjaCB0byBjYWxsIGEgaG90cGx1ZyBkZXZpY2Ut cG93ZXIgYWdlbnQgd2hlbiB0aGUgcG93ZXIgc3RhdGUgb2YgYQo+PmRldmljZSBpcyBtb2RpZmll ZCBhdCBydW50aW1lICh0aGF0IGlzLCBpbmRpdmlkdWFsbHkgdmlhIHN5c2ZzIG9yIGJ5IGEKPj5k cml2ZXIgY2FsbCwgbm90IGFzIHBhcnQgb2YgYSBzeXN0ZW0gc3VzcGVuZC9yZXN1bWUpLiAgQWxs b3dzIGEgcG93ZXIKPj5tYW5hZ2VtZW50IGFwcGxpY2F0aW9uIHRvIGJlIGluZm9ybWVkIG9mIGNo YW5nZXMgaW4gZGV2aWNlIHBvd2VyIG5lZWRzLgo+PlRoaXMgY2FuIGJlIHVzZWZ1bCBvbiBwbGF0 Zm9ybXMgd2l0aCBkZXBlbmRlbmNpZXMgYmV0d2VlbiBzeXN0ZW0KPj5jbG9jay92b2x0YWdlIHNl dHRpbmdzIGFuZCBvcGVyYXRpb24gb2YgY2VydGFpbiBkZXZpY2VzIChzdWNoIGFzCj4+UFhBMjd4 KSwgb3IsIGZvciBleGFtcGxlLCBvbiBhIGNlbGwgcGhvbmUgd2hlcmUgdm9pY2ViYW5kIG9yIG5l dHdvcmsKPj5kZXZpY2VzIGdvaW5nIGluYWN0aXZlIHNpZ25hbHMgYW4gb3Bwb3J0dW5pdHkgdG8g bG93ZXIgcGxhdGZvcm0gcG93ZXIKPj5sZXZlbHMgdG8gY29uc2VydmUgYmF0dGVyeSBsaWZlLgo+ IAo+IAo+IFdoeT8gSWYgdGhlIGRldmljZSBpcyBwb3dlcmVkIGRvd24gYXQgcnVudGltZSB2aWEg c3lzZnMsIHRoZW4gdGhlIGFwcCB0aGF0Cj4gZGlkIHRoYXQgYWxyZWFkeSBleGlzdHMgaW4gdXNl cnNwYWNlLCBsaWtlIHRoZSBvbmVzIHlvdSdyZSB0cnlpbmcgdG8KPiBub3RpZnkgdmlhIC9zYmlu L2hvdHBsdWcuIEl0IHdvdWxkIGJlIG11Y2ggc2ltcGxlciBmb3IgdGhlIGZpcnN0IGFwcCB0bwo+ IGdlbmVyYXRlIGUuZy4gYSBkLWJ1cyBtZXNzYWdlIHRvIG5vdGlmeSBvdGhlciBhcHBzLCByYXRo ZXIgdGhhbiBjcmVhdGluZwo+IHRoaXMgY29uZHVpdCB0aHJvdWdoIHRoZSBrZXJuZWwuCgpUaGUg YWJpbGl0eSB0byBkbyB0aGlzIHdhcyBvcmlnaW5hbGx5IHJlcXVlc3RlZCBpbiB0aGUgY29udGV4 dCBvZiBhIApkcml2ZXIgbWFuYWdpbmcgdGhlIHBvd2VyIHN0YXRlIG9mIGl0cyBkZXZpY2VzIChh Y2NvcmRpbmcgdG8gc29tZSAKdW5zcGVjaWZpZWQgbG9naWMpOyBhZ3JlZWQgdGhhdCBzdGF0ZSBj aGFuZ2VzIHJlcXVlc3RlZCB2aWEgc3lzZnMgYXJlIGEgCmxlc3MgY29tcGVsbGluZyB1c2FnZSBz Y2VuYXJpby4gIFNtYWxsIGJhdHRlcnktcG93ZXJlZCBnYWRnZXRzIG9mdGVuIAppbXBsZW1lbnQg ZHJpdmVycyB0aGF0IGFyZSBtb3JlIGFjdGl2ZWx5IGludm9sdmVkIGluIG1hbmFnaW5nIHBvd2Vy IApzdGF0ZSB0aGFuIHRoZSBkZXNrdG9wL25vdGVib29rL3NlcnZlciBub3JtLCBpbnZva2luZyBM RE0gc3VzcGVuZCAKcm91dGluZXMgd2hlbiBhbiBvcHBvcnR1bml0eSB0byBwb3dlciBkb3duIGFy aXNlcy4gIEJ1dCBpdCBpcyBhbHNvIApjb21tb24gaW4gd2FsbC1wbHVnLXdpcmVkIHN5c3RlbXMg dG8gaGF2ZSBhIGZldyBwb3dlciBzdGF0ZSB0cmFuc2l0aW9ucyAKdGhhdCByZXN1bHQgZnJvbSB0 aGluZ3MgdW5kZXIga2VybmVsIGNvbnRyb2wsIHN1Y2ggYXMgYmxhbmtpbmcgYSBkaXNwbGF5IApk ZXZpY2UgYWZ0ZXIgYSB0aW1lciBleHBpcmVzLgoKSW4gbWFueSBjYXNlcywgdGhlIG9wcG9ydHVu aXR5IHRvIG1vdmUgdG8gYSBsb3dlci1wb3dlciBzdGF0ZSBtYXkgYmUgCnRyaWdnZXJlZCBieSB1 c2Vyc3BhY2UgYWN0aXZpdHkgYW5kIHdvdWxkIG1ha2UgYSBnb29kIGNhbmRpZGF0ZSBmb3IgYSAK cHVyZWx5IHVzZXJzcGFjZSBub3RpZmljYXRpb24gbWV0aG9kLiAgSG93ZXZlciwgYSBrZXJuZWwt dG8tdXNlcnNwYWNlIApub3RpZmljYXRpb24gbWV0aG9kIGlzIHN1Z2dlc3RlZCBmb3IgdGhpcyB0 byBjb3ZlciBwb3RlbnRpYWwgY2FzZXMgd2hlcmUgCmEgZGV2aWNlIHBvd2VyIHN0YXRlIGNoYW5n ZSBtaWdodCBub3QgYmUgZGlyZWN0bHkgY2F1c2VkIGJ5LCBvciBtYXkgYmUgYSAKbm9uLW9idmlv dXMgc2lkZSBlZmZlY3Qgb2YsIGFuIGFwcGxpY2F0aW9uIGFjdGlvbi4gIERpc3BsYXkgYmxhbmtp bmcgaXMgCmFuIGV4YW1wbGU7IG90aGVyIGRldmljZXMgdGhhdCBjYW4gZW50ZXIgYSBsb3ctcG93 ZXIgc3RhdGUgZHVlIHRvIAppbmFjdGl2aXR5IG9yIGR1ZSB0byBjaGFuZ2VzIGluIHBvd2VyIHN0 YXRlIG9mIG90aGVyIHVwc3RyZWFtIG9yIApkb3duc3RyZWFtIGRldmljZXMgY291bGQgYWxzbyB1 c2UgdGhpcy4gIElmIGFueW9uZSByZWFkaW5nIHRoaXMgaGFzIApjb25jcmV0ZSBleGFtcGxlcyB0 aGF0IHRoZXkgd291bGQgbGlrZSB0byBoYXZlIGNvbnNpZGVyZWQgdGhlbiBwbGVhc2UgZG8gCnNw ZWFrIHVwLgoKSXQgbWF5IGJlIHRoZSBjYXNlIHRoYXQgbW9zdCB1c2VmdWwgc2NlbmFyaW9zIGZv ciB1c2Vyc3BhY2UgYWN0aW9ucyBpbiAKcmVzcG9uc2UgdG8gZGV2aWNlIHBvd2VyIHN0YXRlIGNo YW5nZXMgY291bGQgYmUgaGFuZGxlZCB0aHJvdWdoIGEgCnN1aXRhYmxlIGltcGxlbWVudGF0aW9u IG9mIEQtQlVTIG1lc3NhZ2VzIGJldHdlZW4gYXBwbGljYXRpb25zLCBhbmQgSSdkIApjZXJ0YWlu bHkgc3VwcG9ydCB1c2Ugb2YgdGhhdCBtb2RlbCB3aGVyZXZlciBwb3NzaWJsZS4gIFJldHVybmlu ZyBlcnJvcnMgCnRocm91Z2ggdGhlIHN5c3RlbSBjYWxsIGludGVyZmFjZSBmb3IgYW4gb3BlcmF0 aW9uIG9uIGEgZGV2aWNlIGZpbGUgCmRlc2NyaXB0b3IsIGFzIEkgYmVsaWV2ZSB5b3UndmUgc3Vn Z2VzdGVkLCBtYXkgYWxzbyBoZWxwIGNvdmVyIG1vc3QgCnVzZWZ1bCBjYXNlcy4gIEkgd2lsbCBj b250aW51ZSB0byBlbmNvdXJhZ2UgdGhlIGRldmVsb3BlcnMgd2hvIGhhdmUgCmFza2VkIG1lIGZv ciBkcml2ZXIgcG93ZXIgc3RhdGUgbm90aWZpZXJzIHRvIGNoaW1lIGluIGhlcmUgd2l0aCBtb3Jl IApkZXRhaWxzIG9uIHRoZWlyIG5lZWRzLgoKPiBCZXNpZGVzLCBpZiBvbmUgcHJvY2VzcyBoYXMg YSBkZXZpY2Ugb3BlbiwgdGhlbiB0aGUgZHJpdmVyIHNob3VsZCByZWZ1c2UKPiBhbnkgcmVxdWVz dHMgdG8gcG93ZXIgaXQgZG93bi4KCkknZCBzdWdnZXN0IHNvbWUgbGF0aXR1ZGUgaW4gZHJpdmVy IGhhbmRsaW5nIG9mIGxvdy1wb3dlciBkZXZpY2Ugc3RhdGVzIAp3cnQgb3BlbiBmaWxlIGRlc2Ny aXB0b3JzLCBzdWNoIGFzIGZvciBkaXNwbGF5IGJsYW5raW5nLiAgQnV0IHllcywgdGhpcyAKaXMg dXN1YWxseSB0cnVlIChhdCBsZWFzdCBpbiB0aGUgbm9uLXN5c3RlbS1zdXNwZW5kIGNhc2UpLgoK Ci0tIApUb2RkIFBveW5vcgpNb250YVZpc3RhIFNvZnR3YXJlCgoKCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KVGhpcyBTRi5OZXQgZW1haWwg aXMgc3BvbnNvcmVkIGJ5OiBPcmFjbGUgMTBnCkdldCBjZXJ0aWZpZWQgb24gdGhlIGhvdHRlc3Qg dGhpbmcgZXZlciB0byBoaXQgdGhlIG1hcmtldC4uLiBPcmFjbGUgMTBnLiAKVGFrZSBhbiBPcmFj bGUgMTBnIGNsYXNzIG5vdywgYW5kIHdlJ2xsIGdpdmUgeW91IHRoZSBleGFtIEZSRUUuIApodHRw Oi8vYWRzLm9zZG4uY29tLz9hZF9pZDE0OSZhbGxvY19pZIE2NiZvcD1jbGljawpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpMaW51eC1ob3RwbHVnLWRldmVs IG1haWxpbmcgbGlzdCAgaHR0cDovL2xpbnV4LWhvdHBsdWcuc291cmNlZm9yZ2UubmV0CkxpbnV4 LWhvdHBsdWctZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0Cmh0dHBzOi8vbGlzdHMuc291cmNl Zm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2xpbnV4LWhvdHBsdWctZGV2ZWw= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264048AbUEDUgr (ORCPT ); Tue, 4 May 2004 16:36:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264029AbUEDUgr (ORCPT ); Tue, 4 May 2004 16:36:47 -0400 Received: from gateway-1237.mvista.com ([12.44.186.158]:59125 "EHLO av.mvista.com") by vger.kernel.org with ESMTP id S264048AbUEDUgo (ORCPT ); Tue, 4 May 2004 16:36:44 -0400 Message-ID: <4097FED8.3020003@mvista.com> Date: Tue, 04 May 2004 13:36:40 -0700 From: Todd Poynor User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Patrick Mochel CC: linux-hotplug-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Hotplug for device power state changes References: <20040429202654.GA9971@dhcp193.mvista.com> In-Reply-To: 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 Patrick Mochel wrote: >>A patch to call a hotplug device-power agent when the power state of a >>device is modified at runtime (that is, individually via sysfs or by a >>driver call, not as part of a system suspend/resume). Allows a power >>management application to be informed of changes in device power needs. >>This can be useful on platforms with dependencies between system >>clock/voltage settings and operation of certain devices (such as >>PXA27x), or, for example, on a cell phone where voiceband or network >>devices going inactive signals an opportunity to lower platform power >>levels to conserve battery life. > > > Why? If the device is powered down at runtime via sysfs, then the app that > did that already exists in userspace, like the ones you're trying to > notify via /sbin/hotplug. It would be much simpler for the first app to > generate e.g. a d-bus message to notify other apps, rather than creating > this conduit through the kernel. The ability to do this was originally requested in the context of a driver managing the power state of its devices (according to some unspecified logic); agreed that state changes requested via sysfs are a less compelling usage scenario. Small battery-powered gadgets often implement drivers that are more actively involved in managing power state than the desktop/notebook/server norm, invoking LDM suspend routines when an opportunity to power down arises. But it is also common in wall-plug-wired systems to have a few power state transitions that result from things under kernel control, such as blanking a display device after a timer expires. In many cases, the opportunity to move to a lower-power state may be triggered by userspace activity and would make a good candidate for a purely userspace notification method. However, a kernel-to-userspace notification method is suggested for this to cover potential cases where a device power state change might not be directly caused by, or may be a non-obvious side effect of, an application action. Display blanking is an example; other devices that can enter a low-power state due to inactivity or due to changes in power state of other upstream or downstream devices could also use this. If anyone reading this has concrete examples that they would like to have considered then please do speak up. It may be the case that most useful scenarios for userspace actions in response to device power state changes could be handled through a suitable implementation of D-BUS messages between applications, and I'd certainly support use of that model wherever possible. Returning errors through the system call interface for an operation on a device file descriptor, as I believe you've suggested, may also help cover most useful cases. I will continue to encourage the developers who have asked me for driver power state notifiers to chime in here with more details on their needs. > Besides, if one process has a device open, then the driver should refuse > any requests to power it down. I'd suggest some latitude in driver handling of low-power device states wrt open file descriptors, such as for display blanking. But yes, this is usually true (at least in the non-system-suspend case). -- Todd Poynor MontaVista Software