From: Nigel Cunningham <nigel@nigel.suspend2.net>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: pm list <linux-pm@lists.osdl.org>,
LKML <linux-kernel@vger.kernel.org>,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: NAK new drivers without proper power management?
Date: Sat, 10 Feb 2007 10:28:10 +1100 [thread overview]
Message-ID: <1171063690.1484.113.camel@nigel.suspend2.net> (raw)
In-Reply-To: <200702100012.17430.rjw@sisk.pl>
Hi.
On Sat, 2007-02-10 at 00:12 +0100, Rafael J. Wysocki wrote:
> > > I think if CONFIG_PM_DEBUG is set, the core should warn about drivers not
> > > having .suspend or .resume routines.
> >
> > The only problem with that is, not everyone turns on CONFIG_PM_DEBUG.
> > CONFIG_PM instead?
>
> Well, I can imagine a driver that doesn't need a .suspend routine, for example,
> and I don't think we should make the kernel always complain about that.
How about...
#ifdef CONFIG_PM_PARANOIA
static int empty_suspend_routine(struct device *dev, pm_message_t state)
{
return 0;
}
#define empty_suspend empty_suspend_routine
#else
#define empty_suspend NULL
#endif
...
.suspend = empty_suspend;
...
Then CONFIG_PM_PARANOIA can be enabled by default for now, and when we
eventually device it's not needed anymore, someone can submit a patch
replacing either turning off the CONFIG by default or removing the whole
mechanism.
> I think if someone doesn't set CONFIG_PM_DEBUG, we can ask him to set it
> and report back.
We can, but the whole point to the suggestion was to make your life and
mine easier, as well as those of our users.
Making it dependent on CONFIG_PM instead achieves that by:
- Saving you, I and distro people from having to tell their users to
enable the option (and how to)
- Saving the users the problem of going through all the steps, making
mistakes, potentially ending up with unbootable systems because they
make mistakes and so on.
This way, they just need to look in dmesg.
Regards,
Nigel
next prev parent reply other threads:[~2007-02-09 23:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1171058269.1484.64.camel@nigel.suspend2.net>
[not found] ` <1171059433.8675.195.camel@laptopd505.fenrus.org>
[not found] ` <1171059968.1484.90.camel@nigel.suspend2.net>
2007-02-09 22:44 ` NAK new drivers without proper power management? Rafael J. Wysocki
2007-02-09 22:51 ` Nigel Cunningham
2007-02-09 23:12 ` Rafael J. Wysocki
2007-02-09 23:28 ` Nigel Cunningham [this message]
2007-02-10 0:12 ` Rafael J. Wysocki
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=1171063690.1484.113.camel@nigel.suspend2.net \
--to=nigel@nigel.suspend2.net \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=rjw@sisk.pl \
/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