From: "Rafael J. Wysocki" <rjw@sisk.pl> To: Daniel Barkalow <barkalow@iabervon.org> Cc: nigel@nigel.suspend2.net, Robert Hancock <hancockr@shaw.ca>, linux-kernel <linux-kernel@vger.kernel.org>, Jeff Garzik <jeff@garzik.org>, Pavel Machek <pavel@ucw.cz>, pm list <linux-pm@lists.osdl.org> Subject: Re: [PATCH] Re: NAK new drivers without proper power management? Date: Sat, 10 Feb 2007 20:50:27 +0100 [thread overview] Message-ID: <200702102050.28218.rjw@sisk.pl> (raw) In-Reply-To: <Pine.LNX.4.64.0702101231281.20138@iabervon.org> On Saturday, 10 February 2007 18:52, Daniel Barkalow wrote: > On Sat, 10 Feb 2007, Rafael J. Wysocki wrote: > > > On Saturday, 10 February 2007 11:02, Nigel Cunningham wrote: > > > > > Well, the original desire was to stop new drivers getting in without > > > proper power management. > > > > I know, but I agree with the argument that having a driver without the > > suspend/resume support is better than not having the driver at all. > > How about if "proper power management" is defined to include the driver > explicitly preventing suspend? It seems to me like the current problem is > that driver writers don't think about power management at all, and the > result is that, after suspend/resume, the system doesn't come back. It > would be better if driver writers had to think about power management just > enough to realize that it's not going to work, and make this information > available to the system. At that point, it's relatively easy for the > system to do something useful about it. Actually, it is easy for the driver authors to do this right now. They can just make the .suspend() routine always return an error. Well, I think this is a good idea: if the device in question requires specific power management during the suspend/resume, but it is not implemented by the driver, we should require the author of the driver to define the .suspend() routine that returns -ENOSYS (preferably, with an explanatory warning in dmesg). Thoughts? > > Also, I think there are quite some drivers already in the tree that don't > > support suspend/resume explicitly and honestly we should start from adding the > > suspend/resume routines to these drivers _before_ we ban new drivers like that. > > It'd be relatively quick to modify all the current drivers that don't > explicitly support suspend/resume to explicitly not support it. (Or to > explicitly support it trivially; /dev/null obviously doesn't need > anything.) The problem is we have to review quite a lot of drivers for this purpose. Still it looks like we should do this anyway. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King
WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@sisk.pl> To: Daniel Barkalow <barkalow@iabervon.org> Cc: Robert Hancock <hancockr@shaw.ca>, Jeff Garzik <jeff@garzik.org>, Pavel Machek <pavel@ucw.cz>, pm list <linux-pm@lists.osdl.org>, linux-kernel <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] Re: NAK new drivers without proper power management? Date: Sat, 10 Feb 2007 20:50:27 +0100 [thread overview] Message-ID: <200702102050.28218.rjw@sisk.pl> (raw) In-Reply-To: <Pine.LNX.4.64.0702101231281.20138@iabervon.org> On Saturday, 10 February 2007 18:52, Daniel Barkalow wrote: > On Sat, 10 Feb 2007, Rafael J. Wysocki wrote: > > > On Saturday, 10 February 2007 11:02, Nigel Cunningham wrote: > > > > > Well, the original desire was to stop new drivers getting in without > > > proper power management. > > > > I know, but I agree with the argument that having a driver without the > > suspend/resume support is better than not having the driver at all. > > How about if "proper power management" is defined to include the driver > explicitly preventing suspend? It seems to me like the current problem is > that driver writers don't think about power management at all, and the > result is that, after suspend/resume, the system doesn't come back. It > would be better if driver writers had to think about power management just > enough to realize that it's not going to work, and make this information > available to the system. At that point, it's relatively easy for the > system to do something useful about it. Actually, it is easy for the driver authors to do this right now. They can just make the .suspend() routine always return an error. Well, I think this is a good idea: if the device in question requires specific power management during the suspend/resume, but it is not implemented by the driver, we should require the author of the driver to define the .suspend() routine that returns -ENOSYS (preferably, with an explanatory warning in dmesg). Thoughts? > > Also, I think there are quite some drivers already in the tree that don't > > support suspend/resume explicitly and honestly we should start from adding the > > suspend/resume routines to these drivers _before_ we ban new drivers like that. > > It'd be relatively quick to modify all the current drivers that don't > explicitly support suspend/resume to explicitly not support it. (Or to > explicitly support it trivially; /dev/null obviously doesn't need > anything.) The problem is we have to review quite a lot of drivers for this purpose. Still it looks like we should do this anyway. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King
next prev parent reply other threads:[~2007-02-10 19:52 UTC|newest] Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <fa.xSKPgY66Q+DPCZ1pszFFfdrJ0To@ifi.uio.no> [not found] ` <fa.FzHdYYYH5Ru57c8/yRxLylpH0Kk@ifi.uio.no> [not found] ` <fa.DuG12yQo+RR4jIjJTnoOwtKM0Ao@ifi.uio.no> [not found] ` <fa.Jy0FJQtASvVEpsy8Q96uoHtyEVA@ifi.uio.no> 2007-02-10 1:50 ` NAK new drivers without proper power management? Robert Hancock 2007-02-10 1:59 ` Lee Revell 2007-02-10 2:09 ` Nigel Cunningham 2007-02-10 2:22 ` Lee Revell 2007-02-10 3:21 ` Kevin Fox 2007-02-10 20:40 ` Adrian Bunk 2007-02-10 4:35 ` Joseph Fannin 2007-02-13 21:08 ` Pavel Machek 2007-02-10 12:47 ` Stefan Richter 2007-02-10 2:05 ` Nigel Cunningham 2007-02-10 3:27 ` Dmitry Torokhov 2007-02-10 4:18 ` Nigel Cunningham 2007-02-10 3:02 ` [PATCH] " Nigel Cunningham 2007-02-10 9:34 ` Rafael J. Wysocki 2007-02-10 9:34 ` Rafael J. Wysocki 2007-02-10 10:02 ` Nigel Cunningham 2007-02-10 10:30 ` Rafael J. Wysocki 2007-02-10 10:30 ` Rafael J. Wysocki 2007-02-10 17:52 ` Daniel Barkalow 2007-02-10 17:52 ` Daniel Barkalow 2007-02-10 19:50 ` Rafael J. Wysocki [this message] 2007-02-10 19:50 ` Rafael J. Wysocki 2007-02-11 6:54 ` Willy Tarreau 2007-02-11 6:54 ` Willy Tarreau 2007-02-11 12:13 ` Matthew Garrett 2007-02-11 13:09 ` Willy Tarreau 2007-02-11 13:09 ` Willy Tarreau 2007-02-11 13:19 ` Matthew Garrett 2007-02-11 13:37 ` Willy Tarreau 2007-02-11 13:37 ` Willy Tarreau 2007-02-11 13:50 ` Rafael J. Wysocki 2007-02-11 13:50 ` Rafael J. Wysocki 2007-02-11 13:57 ` Willy Tarreau 2007-02-11 13:57 ` Willy Tarreau 2007-02-11 14:36 ` Rafael J. Wysocki 2007-02-11 14:36 ` Rafael J. Wysocki 2007-02-11 15:19 ` Pekka Enberg 2007-02-11 15:19 ` Pekka Enberg 2007-02-11 18:31 ` Rafael J. Wysocki 2007-02-11 18:31 ` Rafael J. Wysocki 2007-02-11 17:27 ` Daniel Barkalow 2007-02-11 18:53 ` Rafael J. Wysocki 2007-02-11 18:53 ` Rafael J. Wysocki 2007-02-11 23:06 ` Nigel Cunningham 2007-02-11 23:06 ` Nigel Cunningham 2007-02-11 23:10 ` Rafael J. Wysocki 2007-02-11 23:10 ` Rafael J. Wysocki 2007-02-11 21:04 ` Stefan Richter 2007-02-11 21:04 ` Stefan Richter 2007-02-11 21:10 ` Pavel Machek 2007-02-11 17:36 ` Robert Hancock 2007-02-11 22:49 ` Nigel Cunningham 2007-02-11 19:37 ` Pavel Machek 2007-02-11 19:37 ` Pavel Machek [not found] ` <fa.DhkemAgVI60diqZy0t9GzpwyLmk@ifi.uio.no> [not found] ` <fa.E/NjHlgg0HqDg5CgZjnCHFi2AMM@ifi.uio.no> [not found] ` <fa.kop49l/7yexJoUGrzk6vVeIP934@ifi.uio.no> 2007-02-10 23:20 ` Robert Hancock 2007-02-11 0:44 ` Rafael J. Wysocki 2007-02-11 17:01 ` Pavel Machek 2007-02-11 22:40 ` Nigel Cunningham 2007-02-11 23:29 ` Rafael J. Wysocki 2007-02-11 23:40 ` Nigel Cunningham [not found] ` <fa.EgQN5JpU6xrZSLyOY0kWjJ26hUM@ifi.uio.no> 2007-02-11 18:31 ` Robert Hancock 2007-02-11 21:52 ` Willy Tarreau 2007-02-11 22:26 ` Nigel Cunningham 2007-02-11 22:46 ` Willy Tarreau 2007-02-11 23:18 ` Nigel Cunningham 2007-02-11 23:38 ` Willy Tarreau 2007-02-11 23:45 ` Nigel Cunningham 2007-02-12 0:26 ` Alan 2007-02-12 5:19 ` Willy Tarreau 2007-02-12 20:20 ` Rafael J. Wysocki 2007-02-12 22:36 ` Nigel Cunningham 2007-02-11 23:23 ` Alan 2007-02-11 23:38 ` Rafael J. Wysocki 2007-02-11 23:41 ` Rafael J. Wysocki 2007-02-11 23:47 ` Nigel Cunningham 2007-02-11 23:50 ` Rafael J. Wysocki 2007-02-11 23:55 ` Nigel Cunningham 2007-02-12 0:09 ` Rafael J. Wysocki 2007-02-12 0:15 ` Nigel Cunningham 2007-02-12 12:19 ` Pavel Machek [not found] ` <fa.O1YH4k5KtBGCNs5i2yB17bPvPGw@ifi.uio.no> [not found] ` <fa.RfzClbTP/7B79AoEbQLNj3ABfIk@ifi.uio.no> [not found] ` <fa.AaJ/ugmiUmPO8uC+y1rS9JLuuMc@ifi.uio.no> 2007-02-12 0:59 ` Robert Hancock
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=200702102050.28218.rjw@sisk.pl \ --to=rjw@sisk.pl \ --cc=barkalow@iabervon.org \ --cc=hancockr@shaw.ca \ --cc=jeff@garzik.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@lists.osdl.org \ --cc=nigel@nigel.suspend2.net \ --cc=pavel@ucw.cz \ /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: linkBe 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.