Re: NAK new drivers without proper power management?

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

On Friday, 9 February 2007 23:26, Nigel Cunningham wrote:
> Hi.
> 
> On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote:
> > On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote:
> > > Hi.
> > > 
> > > I don't think this is already done (feel free to correct me if I'm
> > > wrong)..
> > > 
> > > Can we start to NAK new drivers that don't have proper power management
> > > implemented? There really is no excuse for writing a new driver and not
> > > putting .suspend and .resume methods in anymore, is there?
> > 
> > 
> > to a large degree, a device driver that doesn't suspend is better than
> > no device driver at all, right?
> 
> I'm not sure it is. It only makes more work for everyone else: We have
> to help people figure out what causes their computer to fail to resume
> (which can take quite a while), then get them them complain to driver
> author, and the driver author has to submit patches to fix it.
> 
> All of this is avoided if they'll just do it right in the first place.
> 
> > now.. if you want to make the core warn about it, that's very fair
> 
> That's probably a good idea too, since I'm only suggesting this for new
> drivers.

I think if CONFIG_PM_DEBUG is set, the core should warn about drivers not
having .suspend or .resume routines.

Greetings,
Rafael


-- 
If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

Hi.

On Fri, 2007-02-09 at 23:44 +0100, Rafael J. Wysocki wrote:
> On Friday, 9 February 2007 23:26, Nigel Cunningham wrote:
> > Hi.
> > 
> > On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote:
> > > On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote:
> > > > Hi.
> > > > 
> > > > I don't think this is already done (feel free to correct me if I'm
> > > > wrong)..
> > > > 
> > > > Can we start to NAK new drivers that don't have proper power management
> > > > implemented? There really is no excuse for writing a new driver and not
> > > > putting .suspend and .resume methods in anymore, is there?
> > > 
> > > 
> > > to a large degree, a device driver that doesn't suspend is better than
> > > no device driver at all, right?
> > 
> > I'm not sure it is. It only makes more work for everyone else: We have
> > to help people figure out what causes their computer to fail to resume
> > (which can take quite a while), then get them them complain to driver
> > author, and the driver author has to submit patches to fix it.
> > 
> > All of this is avoided if they'll just do it right in the first place.
> > 
> > > now.. if you want to make the core warn about it, that's very fair
> > 
> > That's probably a good idea too, since I'm only suggesting this for new
> > drivers.
> 
> 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?

Regards,

Nigel

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

Hi,

On Friday, 9 February 2007 23:51, Nigel Cunningham wrote:
> Hi.
> 
> On Fri, 2007-02-09 at 23:44 +0100, Rafael J. Wysocki wrote:
> > On Friday, 9 February 2007 23:26, Nigel Cunningham wrote:
> > > Hi.
> > > 
> > > On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote:
> > > > On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote:
> > > > > Hi.
> > > > > 
> > > > > I don't think this is already done (feel free to correct me if I'm
> > > > > wrong)..
> > > > > 
> > > > > Can we start to NAK new drivers that don't have proper power management
> > > > > implemented? There really is no excuse for writing a new driver and not
> > > > > putting .suspend and .resume methods in anymore, is there?
> > > > 
> > > > 
> > > > to a large degree, a device driver that doesn't suspend is better than
> > > > no device driver at all, right?
> > > 
> > > I'm not sure it is. It only makes more work for everyone else: We have
> > > to help people figure out what causes their computer to fail to resume
> > > (which can take quite a while), then get them them complain to driver
> > > author, and the driver author has to submit patches to fix it.
> > > 
> > > All of this is avoided if they'll just do it right in the first place.
> > > 
> > > > now.. if you want to make the core warn about it, that's very fair
> > > 
> > > That's probably a good idea too, since I'm only suggesting this for new
> > > drivers.
> > 
> > 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.

I think if someone doesn't set CONFIG_PM_DEBUG, we can ask him to set it
and report back.

Greetings,
Rafael

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

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

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

On Saturday, 10 February 2007 00:28, Nigel Cunningham wrote:
> 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 that would be tempting people to abuse it, for example by defining or
undefining things just to quieten the warning.

In my opinion the only way to make the warning go away should be to define
a non-NULL .suspend (.resume) routine and that's why I don't think the warning
should be mandatory.

> > 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)

I think the distro people can patch their kernels to fit their needs.

> - 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.

Well, IMO, if someone doesn't know how to compile and install the kernel,
he'll be using a distro kernel anyway and then see above.  Otherwise we can
safely ask him to turn on whatever debugging options we need.

Greetings,
Rafael


-- 
If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King