NAK new drivers without proper power management?

NAK new drivers without proper power management?

[Nigel Cunningham]

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?

Regards,

Nigel-getting-sick-of-drivers-without-pm-support Cunningham

Re: NAK new drivers without proper power management?

[Arjan van de Ven]

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?
now.. if you want to make the core warn about it, that's very fair

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

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.

Regards,

Nigel

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?

[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?

[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?

[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?

[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

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

Re: NAK new drivers without proper power management?

[Jeff Garzik]

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.

A lot of a lot of things could have been avoided, if they just did it 
right the first time.

I think it's more valuable to users to get a basic network driver that 
pings or a basic ATA driver that reads/writes, than peripheral issues 
like suspend/resume.

Certainly we should ask for it, but it shouldn't be a merge-stopper.

	Jeff

Re: NAK new drivers without proper power management?

[Matthew Garrett]

On Sat, Feb 10, 2007 at 08:57:49AM +1100, Nigel Cunningham wrote:

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

The PCI layer is able to deal with drivers that have no PM methods in 
the most simple case.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

Hi.

On Sat, 2007-02-10 at 03:42 +0000, Matthew Garrett wrote:
> On Sat, Feb 10, 2007 at 08:57:49AM +1100, Nigel Cunningham wrote:
> 
> > 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?
> 
> The PCI layer is able to deal with drivers that have no PM methods in 
> the most simple case.

Yeah. I suppose we could use a pm_safe bit flag in struct device_driver
and/or struct pci_driver. I have other things to do right now, but will
seek to understand the relationship between those structs better later.

Regards,

Nigel

Re: NAK new drivers without proper power management?

[Willy Tarreau]

On Fri, Feb 09, 2007 at 07:25:34PM -0500, Jeff Garzik wrote:
> 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.
> 
> A lot of a lot of things could have been avoided, if they just did it 
> right the first time.
> 
> I think it's more valuable to users to get a basic network driver that 
> pings or a basic ATA driver that reads/writes, than peripheral issues 
> like suspend/resume.

100% agreed.

I've been used to a notebook (VAIO) which did not correctly shut down, and
did not support reboot. Now the one I have behaves normally on both features.
I've never ever felt the need for suspend/resume, that I've always attributed
to "geeks" requirements. I had to debug the shutdown code myself for the
previous notebook, and discovered that it was caused by bugs in the ACPI
state transitions for suspend and such fancy features. I would really have
prefered that the people writing the ACPI code had focused first on power-on/
power-off before the rest.

> Certainly we should ask for it, but it shouldn't be a merge-stopper.

I think we should even proceed in the opposite direction : refuse to suspend
if at least one driver does not support the feature, and enumerate the
faulty drivers on the console. While I agree that a machine which resumes
in a bad state is not funny at all to debug, at least when the user expects
his notebook to suspend and sees that it refuses, he can complain about the
drivers which do not support it, and can even unload them first if unneeded.

Regards,
Willy

Re: NAK new drivers without proper power management?

[Arjan van de Ven]

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

so we make the kernel printk on suspend if there are devices without
suspend/resume. Heck, make a config option that prints that at modprobe
time.


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: NAK new drivers without proper power management?

[Pavel Machek]

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?
> now.. if you want to make the core warn about it, that's very fair

Well, driver that is broken on SMP is arguably better than no driver
at all, yet we'd probably avoid merging that. It would be nice to
start including suspend in 'must work' list...
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

Hi,

On Saturday, 10 February 2007 20:38, Pavel Machek 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?
> > now.. if you want to make the core warn about it, that's very fair
> 
> Well, driver that is broken on SMP is arguably better than no driver
> at all, yet we'd probably avoid merging that. It would be nice to
> start including suspend in 'must work' list...

What about this:

"If the device requires that, implement .suspend and .resume or at least
define .suspend that will always return -ENOSYS (then people will know they
have to unload the driver before the suspend).  Similarly, if you aren't sure
whether or not the device requires .suspend and .resume, define .suspend that
will always return -ENOSYS."

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 Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote:
> Hi,
> 
> On Saturday, 10 February 2007 20:38, Pavel Machek 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?
> > > now.. if you want to make the core warn about it, that's very fair
> > 
> > Well, driver that is broken on SMP is arguably better than no driver
> > at all, yet we'd probably avoid merging that. It would be nice to
> > start including suspend in 'must work' list...
> 
> What about this:
> 
> "If the device requires that, implement .suspend and .resume or at least
> define .suspend that will always return -ENOSYS (then people will know they
> have to unload the driver before the suspend).  Similarly, if you aren't sure
> whether or not the device requires .suspend and .resume, define .suspend that
> will always return -ENOSYS."

If your device requires power management, and you know it requires power
management, why not just implement power management? Doing -ENOSYS
instead is like saying -ESPAMMEBECAUSEIMLAZY.

Let me put it another way: People keep talking about Linux being ready
for the desktop. To me at least (but I dare say for lots of other people
too), being ready for the desktop means that things just work, without
having to recompile kernels or bug driver authors or wait twelve
months. 

And it means that doing a bare minimum isn't enough. We keep claiming
that Open Source is better than Proprietary software. If we accept
half-pie jobs of implementing support for anything - driver power
management support or hibernation support or whatever - as 'good
enough', we're undercutting that argument. Linux's power management
support should - as far as we're able - be at least as good as that
other operating system's and preferably way, way better.

-ENOSYS is just not acceptable.

Regards,

Nigel

Re: NAK new drivers without proper power management?

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 2364 bytes --]

Am 10.02.2007 23:37 schrieb Nigel Cunningham:
> If your device requires power management, and you know it requires power
> management, why not just implement power management? Doing -ENOSYS
> instead is like saying -ESPAMMEBECAUSEIMLAZY.

Like it or not, power management is far from trivial, and people
writing device drivers have limited resources. Calling them lazy
does not help that in the least. If you try to put pressure on them
by refusing to merge their work as long as it doesn't provide this
or that functionality, you *may* end up with a few drivers having
that functionality which otherwise wouldn't, but you *will* also
end up with a number of drivers never making it into the kernel
because their authors just have to give up.

Also, in your argument you neglected a few cases:
- What if my device does not require power management?
- What if I don't know whether my device requires power management?
- What if I know my device would require power management, but don't
  know how to implement it?

> Let me put it another way: People keep talking about Linux being ready
> for the desktop. To me at least (but I dare say for lots of other people
> too), being ready for the desktop means that things just work, without
> having to recompile kernels or bug driver authors or wait twelve
> months. 

Exactly.

> And it means that doing a bare minimum isn't enough. We keep claiming
> that Open Source is better than Proprietary software. If we accept
> half-pie jobs of implementing support for anything - driver power
> management support or hibernation support or whatever - as 'good
> enough', we're undercutting that argument. Linux's power management
> support should - as far as we're able - be at least as good as that
> other operating system's and preferably way, way better.
> 
> -ENOSYS is just not acceptable.

Your argument falls down the moment you consider the alternative:
not merging the driver means that the device won't work at all.
(Given that out-of-tree drivers are actively discouraged, to put
it mildly.) That's arguably farther from "desktop readiness" than
a device not supporting power management.

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
- In theory, there is no difference between theory and practice.
  In practice, there is.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: NAK new drivers without proper power management?

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

Am 10.02.2007 07:43 schrieb Willy Tarreau:
> On Fri, Feb 09, 2007 at 07:25:34PM -0500, Jeff Garzik wrote:

>>>> On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote:
>>>>> Can we start to NAK new drivers that don't have proper power management
>>>>> implemented?
[...]
>> Certainly we should ask for it, but it shouldn't be a merge-stopper.
> 
> I think we should even proceed in the opposite direction : refuse to suspend
> if at least one driver does not support the feature, and enumerate the
> faulty drivers on the console. While I agree that a machine which resumes
> in a bad state is not funny at all to debug, at least when the user expects
> his notebook to suspend and sees that it refuses, he can complain about the
> drivers which do not support it, and can even unload them first if unneeded.

I agree wholeheartedly. That's the correct way to handle this.

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
- In theory, there is no difference between theory and practice.
  In practice, there is.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

On Sunday, 11 February 2007 00:45, Tilman Schmidt wrote:
> Am 10.02.2007 23:37 schrieb Nigel Cunningham:
> > If your device requires power management, and you know it requires power
> > management, why not just implement power management? Doing -ENOSYS
> > instead is like saying -ESPAMMEBECAUSEIMLAZY.
> 
> Like it or not, power management is far from trivial, and people
> writing device drivers have limited resources. Calling them lazy
> does not help that in the least. If you try to put pressure on them
> by refusing to merge their work as long as it doesn't provide this
> or that functionality, you *may* end up with a few drivers having
> that functionality which otherwise wouldn't, but you *will* also
> end up with a number of drivers never making it into the kernel
> because their authors just have to give up.
> 
> Also, in your argument you neglected a few cases:
> - What if my device does not require power management?
> - What if I don't know whether my device requires power management?
> - What if I know my device would require power management, but don't
>   know how to implement it?

Plus:
- What if I'm planning to implement the power managemet, but not just right
now?
 
> > Let me put it another way: People keep talking about Linux being ready
> > for the desktop. To me at least (but I dare say for lots of other people
> > too), being ready for the desktop means that things just work, without
> > having to recompile kernels or bug driver authors or wait twelve
> > months. 
> 
> Exactly.
> 
> > And it means that doing a bare minimum isn't enough. We keep claiming
> > that Open Source is better than Proprietary software. If we accept
> > half-pie jobs of implementing support for anything - driver power
> > management support or hibernation support or whatever - as 'good
> > enough', we're undercutting that argument. Linux's power management
> > support should - as far as we're able - be at least as good as that
> > other operating system's and preferably way, way better.
> > 
> > -ENOSYS is just not acceptable.
> 
> Your argument falls down the moment you consider the alternative:
> not merging the driver means that the device won't work at all.
> (Given that out-of-tree drivers are actively discouraged, to put
> it mildly.) That's arguably farther from "desktop readiness" than
> a device not supporting power management.

Agreed.

Greetings,
Rafael

Re: NAK new drivers without proper power management?

[Willy Tarreau]

Hi Nigel,

On Sun, Feb 11, 2007 at 09:37:06AM +1100, Nigel Cunningham wrote:
> On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote:
(...)
> > What about this:
> > 
> > "If the device requires that, implement .suspend and .resume or at least
> > define .suspend that will always return -ENOSYS (then people will know they
> > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > whether or not the device requires .suspend and .resume, define .suspend that
> > will always return -ENOSYS."
> 
> If your device requires power management, and you know it requires power
> management, why not just implement power management? Doing -ENOSYS
> instead is like saying -ESPAMMEBECAUSEIMLAZY.

No, it means "Not implemented because I don't want to screw that driver with
something I'm not expert in". And it also means "Other people will quickly
notice it and will know how to fix this if they really need it".

> Let me put it another way: People keep talking about Linux being ready
> for the desktop. To me at least (but I dare say for lots of other people
> too), being ready for the desktop means that things just work, without
> having to recompile kernels or bug driver authors or wait twelve
> months. 

It's *one* usage of Linux. For this usage, you could also suggest to stop
supporting UP kernels and always build everything with SMP enabled since
more and more often, people will use multi-core systems. It will exempt
the users from upgrading their kernels when they replace their CPU. We
could also try to chase down all the drivers which do not correctly behave
when the CPU switches to a lower frequency.

> And it means that doing a bare minimum isn't enough. We keep claiming
> that Open Source is better than Proprietary software. If we accept
> half-pie jobs of implementing support for anything - driver power
> management support or hibernation support or whatever - as 'good
> enough', we're undercutting that argument. Linux's power management
> support should - as far as we're able - be at least as good as that
> other operating system's and preferably way, way better.
> 
> -ENOSYS is just not acceptable.

Nigel, don't take it as a personal offense, but I think it is a very
centric view of Linux usages. Where I work, Linux is used a lot on
servers and appliances. It is used for mail relays, HTTP proxies,
anti-viruses, firewalls, routers, load balancers, UTM, SSH relays,
etc... Nobody would ever want to enable power management on those
machines, let alone suspend which would cause a major havoc, would
the system decide to enter suspend for any reason.

Many people also have Linux on their notebooks, but as a dual-boot. You
read the word ? "dual-boot". It means that they cleanly shutdown their
system every time they don't use it anymore, and they won't know what
OS they'll use next time.

I've never heard anyone there complaining "oh, I'm fed up with this
boring boot, I always have to wait 30 seconds when I need to do
something, I wish I could suspend and resume". It is considered the
normal way of using their PCs.

So globally, those hundreds of notebooks, workstations and servers
will not be customers of the suspend code any time soon. It would
be a shame to deprive them from working drivers. You must just
accept that a lot of people are not interested in your work. It's
the same for all of us here. I know that a lot of people are not
interested in 2.4 anymore and I'm perfectly fine with that. I'm
not asking 2.6 driver authors to ensure that their driver is easy
to backport for instance.

What I really think would be a clean solution would be sort of
a capability. Either the driver *is* suspend/resume-capable, and
the system can be suspended. Or it is not, and the system must
refuse to suspend. It should not be a problem to proceed like
this because drivers which will not support suspend will mainly
be those which will not have to. And if a user occasionnaly
complains that one driver does not support it, at least you will
have a good argument against its author to implement suspend.

Best regards,
Willy

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

On Sunday, 11 February 2007 07:46, Willy Tarreau wrote:
[--snip--]

> What I really think would be a clean solution would be sort of
> a capability. Either the driver *is* suspend/resume-capable, and
> the system can be suspended. Or it is not, and the system must
> refuse to suspend. It should not be a problem to proceed like
> this because drivers which will not support suspend will mainly
> be those which will not have to. And if a user occasionnaly
> complains that one driver does not support it, at least you will
> have a good argument against its author to implement suspend.

I agree, but the suspend/resume safeness has to be somehow indicated by
the driver.  We could add a flag for that, but it would require us to modify
lots of existing drivers (unless there's something obvious I don't see).
However, the driver can effectively say "I'm not suspend/resume-safe" by
returning an error from .suspend(), in which case the system will automatically
refuse to suspend.

Greetings,
Rafael

Re: NAK new drivers without proper power management?

[Pavel Machek]

Hi!

> > > > 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?
> > > now.. if you want to make the core warn about it, that's very fair
> > 
> > Well, driver that is broken on SMP is arguably better than no driver
> > at all, yet we'd probably avoid merging that. It would be nice to
> > start including suspend in 'must work' list...
> 
> What about this:
> 
> "If the device requires that, implement .suspend and .resume or at least
> define .suspend that will always return -ENOSYS (then people will know they
> have to unload the driver before the suspend).  Similarly, if you aren't sure
> whether or not the device requires .suspend and .resume, define .suspend that
> will always return -ENOSYS."

Sounds ok to me. Where should this text go?
Documentation/SubmittingDrivers ?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: NAK new drivers without proper power management?

[Alan]

> > "If the device requires that, implement .suspend and .resume or at least
> > define .suspend that will always return -ENOSYS (then people will know they
> > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > whether or not the device requires .suspend and .resume, define .suspend that
> > will always return -ENOSYS."
> 
> Sounds ok to me. Where should this text go?
> Documentation/SubmittingDrivers ?

And testing/submitting drivers, perhaps with additional text in that to
make it clear we want suspend/resume support or good excuses

"Please verify your driver correctly handles suspend and resume. If it
does not your patch submission is likely to be suspended and only resume
when the driver correctly handles this feature"

Re: NAK new drivers without proper power management?

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

Am 11.02.2007 20:42 schrieb Pavel Machek:
[...]
>> What about this:
>>
>> "If the device requires that, implement .suspend and .resume or at least
>> define .suspend that will always return -ENOSYS (then people will know they
>> have to unload the driver before the suspend).  Similarly, if you aren't sure
>> whether or not the device requires .suspend and .resume, define .suspend that
>> will always return -ENOSYS."
> 
> Sounds ok to me. Where should this text go?
> Documentation/SubmittingDrivers ?


Documentation/power/devices.txt?

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
- In theory, there is no difference between theory and practice.
  In practice, there is.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

Hi.

On Sun, 2007-02-11 at 00:45 +0100, Tilman Schmidt wrote:
> Am 10.02.2007 23:37 schrieb Nigel Cunningham:
> > If your device requires power management, and you know it requires power
> > management, why not just implement power management? Doing -ENOSYS
> > instead is like saying -ESPAMMEBECAUSEIMLAZY.
> 
> Like it or not, power management is far from trivial, and people
> writing device drivers have limited resources. Calling them lazy
> does not help that in the least. If you try to put pressure on them
> by refusing to merge their work as long as it doesn't provide this
> or that functionality, you *may* end up with a few drivers having
> that functionality which otherwise wouldn't, but you *will* also
> end up with a number of drivers never making it into the kernel
> because their authors just have to give up.

It's not that complex. All we're really talking about is a bit of extra
code to cleanup and configure hardware state; things that the driver
author already knows how to do. S3 might require a bit more
initialisation if firmware needs to be reloaded or more extensive
configuration needs to be done, but if there's firmware to be loaded,
there is a reasonably good probability that we loaded it from Linux to
start with anyway.

> Also, in your argument you neglected a few cases:
> - What if my device does not require power management?

Then you as a generic routine that does nothing but return success
(potentially shared with other drivers that are in the same situation).

> - What if I don't know whether my device requires power management?

The questions are straight forward: Is there hardware state that needs
to be configured if you've just booted the computer and nothing else has
touched it? If so, that needs to be done in a resume method. Do you need
to clean up state prior to doing the things in the resume method, or
otherwise do things to quiesce the driver? If so, they will need to be
done in the suspend method. The result will be roughly similar to what
you do for module load/unload, except maybe less complete in some cases.

> - What if I know my device would require power management, but don't
>   know how to implement it?

I've just told you above :) Now you know!

> > Let me put it another way: People keep talking about Linux being ready
> > for the desktop. To me at least (but I dare say for lots of other people
> > too), being ready for the desktop means that things just work, without
> > having to recompile kernels or bug driver authors or wait twelve
> > months. 
> 
> Exactly.
> 
> > And it means that doing a bare minimum isn't enough. We keep claiming
> > that Open Source is better than Proprietary software. If we accept
> > half-pie jobs of implementing support for anything - driver power
> > management support or hibernation support or whatever - as 'good
> > enough', we're undercutting that argument. Linux's power management
> > support should - as far as we're able - be at least as good as that
> > other operating system's and preferably way, way better.
> > 
> > -ENOSYS is just not acceptable.
> 
> Your argument falls down the moment you consider the alternative:
> not merging the driver means that the device won't work at all.
> (Given that out-of-tree drivers are actively discouraged, to put
> it mildly.) That's arguably farther from "desktop readiness" than
> a device not supporting power management.

I disagree (but I would, of course!). If we apply your logic
consistently, we should merge the driver as soon as any code is written
for it (anything is better than nothing). I'm simply arguing that a
driver that handling suspend and resume should be as much of a
requirement as not causing memory corruption or such like are.

Regards,

Nigel

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

On Sun, 2007-02-11 at 01:27 +0100, Rafael J. Wysocki wrote:
> On Sunday, 11 February 2007 00:45, Tilman Schmidt wrote:
> > Am 10.02.2007 23:37 schrieb Nigel Cunningham:
> > > If your device requires power management, and you know it requires power
> > > management, why not just implement power management? Doing -ENOSYS
> > > instead is like saying -ESPAMMEBECAUSEIMLAZY.
> > 
> > Like it or not, power management is far from trivial, and people
> > writing device drivers have limited resources. Calling them lazy
> > does not help that in the least. If you try to put pressure on them
> > by refusing to merge their work as long as it doesn't provide this
> > or that functionality, you *may* end up with a few drivers having
> > that functionality which otherwise wouldn't, but you *will* also
> > end up with a number of drivers never making it into the kernel
> > because their authors just have to give up.
> > 
> > Also, in your argument you neglected a few cases:
> > - What if my device does not require power management?
> > - What if I don't know whether my device requires power management?
> > - What if I know my device would require power management, but don't
> >   know how to implement it?
> 
> Plus:
> - What if I'm planning to implement the power managemet, but not just right
> now?

Why not right now?
 
Regards,

Nigel

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

Hi.

On Sun, 2007-02-11 at 07:46 +0100, Willy Tarreau wrote:
> Hi Nigel,
> 
> On Sun, Feb 11, 2007 at 09:37:06AM +1100, Nigel Cunningham wrote:
> > On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote:
> (...)
> > > What about this:
> > > 
> > > "If the device requires that, implement .suspend and .resume or at least
> > > define .suspend that will always return -ENOSYS (then people will know they
> > > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > > whether or not the device requires .suspend and .resume, define .suspend that
> > > will always return -ENOSYS."
> > 
> > If your device requires power management, and you know it requires power
> > management, why not just implement power management? Doing -ENOSYS
> > instead is like saying -ESPAMMEBECAUSEIMLAZY.
> 
> No, it means "Not implemented because I don't want to screw that driver with
> something I'm not expert in". And it also means "Other people will quickly
> notice it and will know how to fix this if they really need it".

Ok, that was a bit rough. Sorry.

At the same time though, we were talking about new drivers. If you know
enough to implement the rest of the driver, surely you know enough to
implement the power management part too. (See my previous comment about
the similarities to module load/unload code).

> > Let me put it another way: People keep talking about Linux being ready
> > for the desktop. To me at least (but I dare say for lots of other people
> > too), being ready for the desktop means that things just work, without
> > having to recompile kernels or bug driver authors or wait twelve
> > months. 
> 
> It's *one* usage of Linux. For this usage, you could also suggest to stop
> supporting UP kernels and always build everything with SMP enabled since
> more and more often, people will use multi-core systems. It will exempt
> the users from upgrading their kernels when they replace their CPU. We
> could also try to chase down all the drivers which do not correctly behave
> when the CPU switches to a lower frequency.
> 
> > And it means that doing a bare minimum isn't enough. We keep claiming
> > that Open Source is better than Proprietary software. If we accept
> > half-pie jobs of implementing support for anything - driver power
> > management support or hibernation support or whatever - as 'good
> > enough', we're undercutting that argument. Linux's power management
> > support should - as far as we're able - be at least as good as that
> > other operating system's and preferably way, way better.
> > 
> > -ENOSYS is just not acceptable.
> 
> Nigel, don't take it as a personal offense, but I think it is a very
> centric view of Linux usages. Where I work, Linux is used a lot on
> servers and appliances. It is used for mail relays, HTTP proxies,
> anti-viruses, firewalls, routers, load balancers, UTM, SSH relays,
> etc... Nobody would ever want to enable power management on those
> machines, let alone suspend which would cause a major havoc, would
> the system decide to enter suspend for any reason.

I agree.

> Many people also have Linux on their notebooks, but as a dual-boot. You
> read the word ? "dual-boot". It means that they cleanly shutdown their
> system every time they don't use it anymore, and they won't know what
> OS they'll use next time.

Not necessarily. I dual boot our desktop machine, and hibernate both,
using grub to select with OS to run.

> I've never heard anyone there complaining "oh, I'm fed up with this
> boring boot, I always have to wait 30 seconds when I need to do
> something, I wish I could suspend and resume". It is considered the
> normal way of using their PCs.
> 
> So globally, those hundreds of notebooks, workstations and servers
> will not be customers of the suspend code any time soon. It would
> be a shame to deprive them from working drivers. You must just
> accept that a lot of people are not interested in your work. It's
> the same for all of us here. I know that a lot of people are not
> interested in 2.4 anymore and I'm perfectly fine with that. I'm
> not asking 2.6 driver authors to ensure that their driver is easy
> to backport for instance.

Neither am I. I'm just asking that new drivers have power management as
standard.

> What I really think would be a clean solution would be sort of
> a capability. Either the driver *is* suspend/resume-capable, and
> the system can be suspended. Or it is not, and the system must
> refuse to suspend. It should not be a problem to proceed like
> this because drivers which will not support suspend will mainly
> be those which will not have to. And if a user occasionnaly
> complains that one driver does not support it, at least you will
> have a good argument against its author to implement suspend.

Yes, but why should the user have to complain to start with?

Regards,

Nigel

Re: NAK new drivers without proper power management?

[Manu Abraham]

On 2/12/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote:

> Neither am I. I'm just asking that new drivers have power management as
> standard.


What if the hardware doesn't support power management ?

regards,
manu

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

On Sunday, 11 February 2007 22:02, Alan wrote:
> > > "If the device requires that, implement .suspend and .resume or at least
> > > define .suspend that will always return -ENOSYS (then people will know they
> > > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > > whether or not the device requires .suspend and .resume, define .suspend that
> > > will always return -ENOSYS."
> > 
> > Sounds ok to me. Where should this text go?
> > Documentation/SubmittingDrivers ?
> 
> And testing/submitting drivers, perhaps with additional text in that to
> make it clear we want suspend/resume support or good excuses
> 
> "Please verify your driver correctly handles suspend and resume. If it
> does not your patch submission is likely to be suspended and only resume
> when the driver correctly handles this feature"

I have prepared a patch against Documentation/SubmittingDrivers.  Please
have a look.

---
 Documentation/SubmittingDrivers |   12 ++++++++++++
 1 file changed, 12 insertions(+)

Index: linux-2.6.20-git4/Documentation/SubmittingDrivers
===================================================================
--- linux-2.6.20-git4.orig/Documentation/SubmittingDrivers
+++ linux-2.6.20-git4/Documentation/SubmittingDrivers
@@ -87,6 +87,18 @@ Clarity:	It helps if anyone can see how 
 		driver that intentionally obfuscates how the hardware works
 		it will go in the bitbucket.
 
+PM support:	Since Linux is used on many portable and desktop systems, your
+		driver is likely to be used on such a system and therefore it
+		should support basic power management by implementing, if
+		necessary, the .suspend and .resume methods used during the
+		system-wide suspend and resume transitions.  You should verify
+		that your driver correctly handles the suspend and resume, but
+		if you are unable to ensure that, please at least define the
+		.suspend method returning the -ENOSYS ("Function not
+		implemented") error.  Note, however, that in such a case your
+		submission is likely to be suspended and only resumed when the
+		driver correctly handles this feature.
+
 Control:	In general if there is active maintainance of a driver by
 		the author then patches will be redirected to them unless
 		they are totally obvious and without need of checking.

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

Hi.

On Sun, 2007-02-11 at 21:02 +0000, Alan wrote:
> > > "If the device requires that, implement .suspend and .resume or at least
> > > define .suspend that will always return -ENOSYS (then people will know they
> > > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > > whether or not the device requires .suspend and .resume, define .suspend that
> > > will always return -ENOSYS."
> > 
> > Sounds ok to me. Where should this text go?
> > Documentation/SubmittingDrivers ?
> 
> And testing/submitting drivers, perhaps with additional text in that to
> make it clear we want suspend/resume support or good excuses
> 
> "Please verify your driver correctly handles suspend and resume. If it
> does not your patch submission is likely to be suspended and only resume
> when the driver correctly handles this feature"

Maybe make it explicit that testing should be done for both suspend to
ram and to disk, and with the following usage scenarios as applicable?

- built in;
- modular, loaded while suspending but not loaded prior to resume from
disk;
- modular, loaded while suspending and loaded prior to resume from disk;

Regards,

Nigel

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

On Monday, 12 February 2007 00:10, Nigel Cunningham wrote:
> Hi.
> 
> On Sun, 2007-02-11 at 21:02 +0000, Alan wrote:
> > > > "If the device requires that, implement .suspend and .resume or at least
> > > > define .suspend that will always return -ENOSYS (then people will know they
> > > > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > > > whether or not the device requires .suspend and .resume, define .suspend that
> > > > will always return -ENOSYS."
> > > 
> > > Sounds ok to me. Where should this text go?
> > > Documentation/SubmittingDrivers ?
> > 
> > And testing/submitting drivers, perhaps with additional text in that to
> > make it clear we want suspend/resume support or good excuses
> > 
> > "Please verify your driver correctly handles suspend and resume. If it
> > does not your patch submission is likely to be suspended and only resume
> > when the driver correctly handles this feature"
> 
> Maybe make it explicit that testing should be done for both suspend to
> ram and to disk, and with the following usage scenarios as applicable?
> 
> - built in;
> - modular, loaded while suspending but not loaded prior to resume from
> disk;
> - modular, loaded while suspending and loaded prior to resume from disk;

I think we should state the general rule in Documentation/SubmittingDrivers
and give more details in Documentation/power/devices.txt

Greetings,
Rafael

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

Hi.

On Mon, 2007-02-12 at 02:57 +0400, Manu Abraham wrote:
> On 2/12/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote:
> 
> > Neither am I. I'm just asking that new drivers have power management as
> > standard.

> What if the hardware doesn't support power management ?

You would still want to do the cleanup and configuration that you'd do
for module load/unload.

Regards,

Nigel

Re: NAK new drivers without proper power management?

[Pavel Machek]

Hi!

> > > > define .suspend that will always return -ENOSYS (then people will know they
> > > > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > > > whether or not the device requires .suspend and .resume, define .suspend that
> > > > will always return -ENOSYS."
> > > 
> > > Sounds ok to me. Where should this text go?
> > > Documentation/SubmittingDrivers ?
> > 
> > And testing/submitting drivers, perhaps with additional text in that to
> > make it clear we want suspend/resume support or good excuses
> > 
> > "Please verify your driver correctly handles suspend and resume. If it
> > does not your patch submission is likely to be suspended and only resume
> > when the driver correctly handles this feature"
> 
> Maybe make it explicit that testing should be done for both suspend to
> ram and to disk, and with the following usage scenarios as
 > applicable?

Well, for many people s2ram does not work even today... so requiring
them to test it is slightly draconian.

> - built in;
> - modular, loaded while suspending but not loaded prior to resume from
> disk;

These two should be equivalent.

> - modular, loaded while suspending and loaded prior to resume from disk;

Ok.. but I'm not sure how many people will actually test it _that_
thoroughly. "Try to test it" is good enough for a first version. When
suspend is in better shape, we can ask for more.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

Hi.

On Mon, 2007-02-12 at 00:16 +0100, Rafael J. Wysocki wrote:
> On Monday, 12 February 2007 00:10, Nigel Cunningham wrote:
> > Hi.
> > 
> > On Sun, 2007-02-11 at 21:02 +0000, Alan wrote:
> > > > > "If the device requires that, implement .suspend and .resume or at least
> > > > > define .suspend that will always return -ENOSYS (then people will know they
> > > > > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > > > > whether or not the device requires .suspend and .resume, define .suspend that
> > > > > will always return -ENOSYS."
> > > > 
> > > > Sounds ok to me. Where should this text go?
> > > > Documentation/SubmittingDrivers ?
> > > 
> > > And testing/submitting drivers, perhaps with additional text in that to
> > > make it clear we want suspend/resume support or good excuses
> > > 
> > > "Please verify your driver correctly handles suspend and resume. If it
> > > does not your patch submission is likely to be suspended and only resume
> > > when the driver correctly handles this feature"
> > 
> > Maybe make it explicit that testing should be done for both suspend to
> > ram and to disk, and with the following usage scenarios as applicable?
> > 
> > - built in;
> > - modular, loaded while suspending but not loaded prior to resume from
> > disk;
> > - modular, loaded while suspending and loaded prior to resume from disk;
> 
> I think we should state the general rule in Documentation/SubmittingDrivers
> and give more details in Documentation/power/devices.txt

Sounds good.

Regards,

Nigel

Re: NAK new drivers without proper power management?

[Pavel Machek]

Hi!

> > > - built in;
> > > - modular, loaded while suspending but not loaded prior to resume from
> > > disk;
> > > - modular, loaded while suspending and loaded prior to resume from disk;
> > 
> > I think we should state the general rule in Documentation/SubmittingDrivers
> > and give more details in Documentation/power/devices.txt
> 
> Sounds good.

Ok, so who does the patch?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: NAK new drivers without proper power management?

[Manu Abraham]

On 2/12/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote:
> Hi.
>
> On Mon, 2007-02-12 at 02:57 +0400, Manu Abraham wrote:
> > On 2/12/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote:
> >
> > > Neither am I. I'm just asking that new drivers have power management as
> > > standard.
>
> > What if the hardware doesn't support power management ?
>
> You would still want to do the cleanup and configuration that you'd do
> for module load/unload.
>

By adding dummy functions, wouldn't that just look awkward ?

regards,
manu

Re: NAK new drivers without proper power management?

[Pavel Machek]

Hi!

> >> > Neither am I. I'm just asking that new drivers have power management as
> >> > standard.
> >
> >> What if the hardware doesn't support power management ?
> >
> >You would still want to do the cleanup and configuration that you'd do
> >for module load/unload.
> >
> 
> By adding dummy functions, wouldn't that just look awkward ?

No, it is not by dummy functions. Checkout how swsusp works; it needs
no hw support, still it needs driver support.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

Hi.

On Mon, 2007-02-12 at 00:21 +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > define .suspend that will always return -ENOSYS (then people will know they
> > > > > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > > > > whether or not the device requires .suspend and .resume, define .suspend that
> > > > > will always return -ENOSYS."
> > > > 
> > > > Sounds ok to me. Where should this text go?
> > > > Documentation/SubmittingDrivers ?
> > > 
> > > And testing/submitting drivers, perhaps with additional text in that to
> > > make it clear we want suspend/resume support or good excuses
> > > 
> > > "Please verify your driver correctly handles suspend and resume. If it
> > > does not your patch submission is likely to be suspended and only resume
> > > when the driver correctly handles this feature"
> > 
> > Maybe make it explicit that testing should be done for both suspend to
> > ram and to disk, and with the following usage scenarios as
>  > applicable?
> 
> Well, for many people s2ram does not work even today... so requiring
> them to test it is slightly draconian.
> 
> > - built in;
> > - modular, loaded while suspending but not loaded prior to resume from
> > disk;
> 
> These two should be equivalent.

No. The differences are:

Built in: The initcalls will have run, but the driver may or may not
actually have been used, depending on whether it's used before we start
the resume. It should probably be tested with both having been used and
not having been used.
Modular, loaded prior to suspending but not prior to resuming: At resume
time, will still be in whatever config the bios puts it in. No Linux
driver code will have touched it.
Modular, loaded prior to suspending and resuming: Should be equivalent
to built in (module initcalls will have run), but may vary if there's
some difference in code/timing between being a module and built in.
(This shouldn't happen, but that's the point to testing).

> > - modular, loaded while suspending and loaded prior to resume from disk;
> 
> Ok.. but I'm not sure how many people will actually test it _that_
> thoroughly. "Try to test it" is good enough for a first version. When
> suspend is in better shape, we can ask for more.

I'd prefer to ask for what should be done from the start. Will we expect
people to go back and retest if we change the rules, or do we prefer
them to complain "You didn't adequately point out the testing I needed
to do, and I got all these complaints from my users!"

Regards,

Nigel

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

Hi.

On Mon, 2007-02-12 at 03:25 +0400, Manu Abraham wrote:
> On 2/12/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote:
> > Hi.
> >
> > On Mon, 2007-02-12 at 02:57 +0400, Manu Abraham wrote:
> > > On 2/12/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote:
> > >
> > > > Neither am I. I'm just asking that new drivers have power management as
> > > > standard.
> >
> > > What if the hardware doesn't support power management ?
> >
> > You would still want to do the cleanup and configuration that you'd do
> > for module load/unload.
> >
> By adding dummy functions, wouldn't that just look awkward ?

If all you need to do is say 'I don't need to do anything' and we have a
shared function that does that, all we're talking about doing is adding
to your struct pci_device (or whatever)

.resume = generic_empty_resume;

To me at least, that doesn't look awkward, and says cleanly and clearly
that you've checked things over and decided you know what's required.

Regards,

Nigel

Re: NAK new drivers without proper power management?

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 4387 bytes --]

Hi,

Am 11.02.2007 23:37 schrieb Nigel Cunningham:
> On Sun, 2007-02-11 at 00:45 +0100, Tilman Schmidt wrote:
>> Am 10.02.2007 23:37 schrieb Nigel Cunningham:
>>> If your device requires power management, and you know it requires power
>>> management, why not just implement power management? [...]
>> Like it or not, power management is far from trivial, and people
>> writing device drivers have limited resources. [...]
> It's not that complex. All we're really talking about is a bit of extra
> code to cleanup and configure hardware state; things that the driver
> author already knows how to do. S3 might require a bit more
> initialisation if firmware needs to be reloaded or more extensive
> configuration needs to be done, but if there's firmware to be loaded,
> there is a reasonably good probability that we loaded it from Linux to
> start with anyway.

You are assuming a perfect world where driver authors have complete
knowledge of their devices. In reality, many drivers (including
those I have the mixed pleasure of maintaining) are based at least
in part on reverse engineering, and managing power states may well
fall into the domain of things not yet sufficiently reverse
engineered.

>> Also, in your argument you neglected a few cases:
>> - What if my device does not require power management?
> 
> Then you as a generic routine that does nothing but return success
> (potentially shared with other drivers that are in the same situation).

But if I just write an empty routine like that I open myself up to
criticism along the lines of "writing dummy routines just in order
to shut up kernel warnings". BTDT.

>> - What if I don't know whether my device requires power management?
> 
> The questions are straight forward: Is there hardware state that needs
> to be configured if you've just booted the computer and nothing else has
> touched it? If so, that needs to be done in a resume method. Do you need
> to clean up state prior to doing the things in the resume method, or
> otherwise do things to quiesce the driver? If so, they will need to be
> done in the suspend method. The result will be roughly similar to what
> you do for module load/unload, except maybe less complete in some cases.

I don't doubt your basic assessment. However it doesn't translate that
easily into a real implementation. In my case, I maintain a USB driver,
so I have to deal with USB specifics of suspend/resume which happen not
to be that well documented. My driver provides an isdn4linux device but
isdn4linux knows nothing about suspend/resume so I am on my own on how
to reconcile the two. The device itself, though in turn far from trivial,
is actually the least of my worries.

>> - What if I know my device would require power management, but don't
>>   know how to implement it?
> 
> I've just told you above :) Now you know!

No I don't. See above.

>>> -ENOSYS is just not acceptable.
>> Your argument falls down the moment you consider the alternative:
>> not merging the driver means that the device won't work at all.
>> (Given that out-of-tree drivers are actively discouraged, to put
>> it mildly.) That's arguably farther from "desktop readiness" than
>> a device not supporting power management.
> 
> I disagree (but I would, of course!). If we apply your logic
> consistently, we should merge the driver as soon as any code is written
> for it (anything is better than nothing). I'm simply arguing that a
> driver that handling suspend and resume should be as much of a
> requirement as not causing memory corruption or such like are.

Well, that's a common fallacy about applying any logic consistently.
There's a continuum of usefulness from "hardly works at all" through
"causes random memory corruption", "doesn't support power management",
and "does not support some esoteric protocol variety no one ever heard
of anyways" up to "supports any and all uses to which anyone could
possibly want to put the device". I would argue that "doesn't support
power management" is *much* farther up that ladder than, for example,
"causes random memory corruption".

Regards,
Tilman

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

Hi,

On Monday, 12 February 2007 01:10, Tilman Schmidt wrote:
> Hi,
> 
> Am 11.02.2007 23:37 schrieb Nigel Cunningham:
> > On Sun, 2007-02-11 at 00:45 +0100, Tilman Schmidt wrote:
> >> Am 10.02.2007 23:37 schrieb Nigel Cunningham:
> >>> If your device requires power management, and you know it requires power
> >>> management, why not just implement power management? [...]
> >> Like it or not, power management is far from trivial, and people
> >> writing device drivers have limited resources. [...]
> > It's not that complex. All we're really talking about is a bit of extra
> > code to cleanup and configure hardware state; things that the driver
> > author already knows how to do. S3 might require a bit more
> > initialisation if firmware needs to be reloaded or more extensive
> > configuration needs to be done, but if there's firmware to be loaded,
> > there is a reasonably good probability that we loaded it from Linux to
> > start with anyway.
> 
> You are assuming a perfect world where driver authors have complete
> knowledge of their devices. In reality, many drivers (including
> those I have the mixed pleasure of maintaining) are based at least
> in part on reverse engineering, and managing power states may well
> fall into the domain of things not yet sufficiently reverse
> engineered.

Exactly.

> >> Also, in your argument you neglected a few cases:
> >> - What if my device does not require power management?
> > 
> > Then you as a generic routine that does nothing but return success
> > (potentially shared with other drivers that are in the same situation).
> 
> But if I just write an empty routine like that I open myself up to
> criticism along the lines of "writing dummy routines just in order
> to shut up kernel warnings". BTDT.

Well, for me the design that required driver authors to write empty routines
returning success, would be bad.

> >> - What if I don't know whether my device requires power management?
> > 
> > The questions are straight forward: Is there hardware state that needs
> > to be configured if you've just booted the computer and nothing else has
> > touched it? If so, that needs to be done in a resume method. Do you need
> > to clean up state prior to doing the things in the resume method, or
> > otherwise do things to quiesce the driver? If so, they will need to be
> > done in the suspend method. The result will be roughly similar to what
> > you do for module load/unload, except maybe less complete in some cases.
> 
> I don't doubt your basic assessment. However it doesn't translate that
> easily into a real implementation. In my case, I maintain a USB driver,
> so I have to deal with USB specifics of suspend/resume which happen not
> to be that well documented. My driver provides an isdn4linux device but
> isdn4linux knows nothing about suspend/resume so I am on my own on how
> to reconcile the two. The device itself, though in turn far from trivial,
> is actually the least of my worries.
> 
> >> - What if I know my device would require power management, but don't
> >>   know how to implement it?
> > 
> > I've just told you above :) Now you know!
> 
> No I don't. See above.
> 
> >>> -ENOSYS is just not acceptable.
> >> Your argument falls down the moment you consider the alternative:
> >> not merging the driver means that the device won't work at all.
> >> (Given that out-of-tree drivers are actively discouraged, to put
> >> it mildly.) That's arguably farther from "desktop readiness" than
> >> a device not supporting power management.
> > 
> > I disagree (but I would, of course!). If we apply your logic
> > consistently, we should merge the driver as soon as any code is written
> > for it (anything is better than nothing). I'm simply arguing that a
> > driver that handling suspend and resume should be as much of a
> > requirement as not causing memory corruption or such like are.
> 
> Well, that's a common fallacy about applying any logic consistently.
> There's a continuum of usefulness from "hardly works at all" through
> "causes random memory corruption", "doesn't support power management",
> and "does not support some esoteric protocol variety no one ever heard
> of anyways" up to "supports any and all uses to which anyone could
> possibly want to put the device". I would argue that "doesn't support
> power management" is *much* farther up that ladder than, for example,
> "causes random memory corruption".

 I agree with that.  Moreover, I think that the suspend/resume support is
something you _can_ _live_ without while living, for instance, without
networking at all would be difficult these days. Therefore I would certainly
accept the driver that didn't support suspend/resume for my network adapter
and I'd be happy to use it anyway.

On the other hand, it would be nice if that driver did something that would
prevent the system from suspending when it's loaded, just in case.

Greetings,
Rafael

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

On Monday, 12 February 2007 01:28, Alan wrote:
> > +PM support:	Since Linux is used on many portable and desktop systems, your
> > +		driver is likely to be used on such a system and therefore it
> > +		should support basic power management by implementing, if
> > +		necessary, the .suspend and .resume methods used during the
> > +		system-wide suspend and resume transitions.  You should verify
> > +		that your driver correctly handles the suspend and resume, but
> > +		if you are unable to ensure that, please at least define the
> > +		.suspend method returning the -ENOSYS ("Function not
> > +		implemented") error.  Note, however, that in such a case your
> > +		submission is likely to be suspended and only resumed when the
> > +		driver correctly handles this feature.
> 
> I'd lose the last bit. Just end it at "error.", there are going to be
> people who produce good reasons not to handle suspend/resume.

OK, I will.

Re: NAK new drivers without proper power management?

[Alan]

> +PM support:	Since Linux is used on many portable and desktop systems, your
> +		driver is likely to be used on such a system and therefore it
> +		should support basic power management by implementing, if
> +		necessary, the .suspend and .resume methods used during the
> +		system-wide suspend and resume transitions.  You should verify
> +		that your driver correctly handles the suspend and resume, but
> +		if you are unable to ensure that, please at least define the
> +		.suspend method returning the -ENOSYS ("Function not
> +		implemented") error.  Note, however, that in such a case your
> +		submission is likely to be suspended and only resumed when the
> +		driver correctly handles this feature.

I'd lose the last bit. Just end it at "error.", there are going to be
people who produce good reasons not to handle suspend/resume.

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

Howdy!

On Mon, 2007-02-12 at 01:10 +0100, Tilman Schmidt wrote:
> Hi,
> 
> Am 11.02.2007 23:37 schrieb Nigel Cunningham:
> > On Sun, 2007-02-11 at 00:45 +0100, Tilman Schmidt wrote:
> >> Am 10.02.2007 23:37 schrieb Nigel Cunningham:
> >>> If your device requires power management, and you know it requires power
> >>> management, why not just implement power management? [...]
> >> Like it or not, power management is far from trivial, and people
> >> writing device drivers have limited resources. [...]
> > It's not that complex. All we're really talking about is a bit of extra
> > code to cleanup and configure hardware state; things that the driver
> > author already knows how to do. S3 might require a bit more
> > initialisation if firmware needs to be reloaded or more extensive
> > configuration needs to be done, but if there's firmware to be loaded,
> > there is a reasonably good probability that we loaded it from Linux to
> > start with anyway.
> 
> You are assuming a perfect world where driver authors have complete
> knowledge of their devices. In reality, many drivers (including
> those I have the mixed pleasure of maintaining) are based at least
> in part on reverse engineering, and managing power states may well
> fall into the domain of things not yet sufficiently reverse
> engineered.

Nope. I'm assuming that the driver author knows what needs to be done to
get the driver out of whatever state the BIOS puts it in to start with,
and into an operational state, and that they therefore also know what
needs to be done to take it out of the operational state again. I'm
admitting that there's also another state - the post suspend-to-ram
driver state - that they may not know how to deal with. But for
suspend-to-disk, if you know how to get the driver to work in the first
place, you know enough to stop it working (.suspend) and start it up
again (.resume) for the hibernate case at least.

I'm not assuming that you know enough to be able to put the driver into
a low state and get it out again. This is definitely preferable, and at
least possibly essential for suspend to ram, but for some unknown reason
I'm quite hibernation focused, and for that, just the above is
sufficient.

> >> Also, in your argument you neglected a few cases:
> >> - What if my device does not require power management?
> > 
> > Then you as a generic routine that does nothing but return success
> > (potentially shared with other drivers that are in the same situation).
> 
> But if I just write an empty routine like that I open myself up to
> criticism along the lines of "writing dummy routines just in order
> to shut up kernel warnings". BTDT.

Well, it might not be completely empty. I think someone already pointed
out that there's a minimal workset for the pci bus that pci drivers
would want to invoke. But we wouldn't (rightly) accuse you of such
things if we decided that the policy was "Every driver ought to have a
resume routine, even if it's just a minimal I-just-work route".

> >> - What if I don't know whether my device requires power management?
> > 
> > The questions are straight forward: Is there hardware state that needs
> > to be configured if you've just booted the computer and nothing else has
> > touched it? If so, that needs to be done in a resume method. Do you need
> > to clean up state prior to doing the things in the resume method, or
> > otherwise do things to quiesce the driver? If so, they will need to be
> > done in the suspend method. The result will be roughly similar to what
> > you do for module load/unload, except maybe less complete in some cases.
> 
> I don't doubt your basic assessment. However it doesn't translate that
> easily into a real implementation. In my case, I maintain a USB driver,
> so I have to deal with USB specifics of suspend/resume which happen not
> to be that well documented. My driver provides an isdn4linux device but
> isdn4linux knows nothing about suspend/resume so I am on my own on how
> to reconcile the two. The device itself, though in turn far from trivial,
> is actually the least of my worries.

Mmm, so that's a case where we need to prod those who write
documentation and bus support first. You're probably closer! :)

Regards,

Nigel

Re: NAK new drivers without proper power management?

[Geert Uytterhoeven]

On Sat, 10 Feb 2007, Rafael J. Wysocki wrote:
> What about this:
> 
> "If the device requires that, implement .suspend and .resume or at least
                                                                  ^^^^^^^^
> define .suspend that will always return -ENOSYS (then people will know they
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> have to unload the driver before the suspend).  Similarly, if you aren't sure
> whether or not the device requires .suspend and .resume, define .suspend that
                                                           ^^^^^^^^^^^^^^^^^^^^
> will always return -ENOSYS."
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
Can't the upper layer just assume -ENOSYS if .resume/.suspend is NULL?
It's nicer if you don't have to implement dummy functions at all.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: NAK new drivers without proper power management?

[Arjan van de Ven]

> 
> By adding dummy functions, wouldn't that just look awkward ?

not really; if you have a template


pm_no_suspend_needed
and
pm_no_restore_needed

functions, and just make it part of ALL device structs that don't need
it.. it's not that bad

or maybe 

pm_generic_no_suspend
pm_generic_no_resume

as names, more in line what we use elsewhere in the kernel
-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: NAK new drivers without proper power management?

[Gerhard Mack]

On Sun, 11 Feb 2007, Willy Tarreau wrote:

> On Sun, Feb 11, 2007 at 09:37:06AM +1100, Nigel Cunningham wrote:
> > On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote:
> 
> Many people also have Linux on their notebooks, but as a dual-boot. You
> read the word ? "dual-boot". It means that they cleanly shutdown their
> system every time they don't use it anymore, and they won't know what
> OS they'll use next time.

Please tell me your joking.  Linux' crappy suspend support is a common 
reason people give me for not wanting Linux anywhere near their laptops.  

I have a single boot laptop that's somewhat of a mobile debugging station 
that needs Linux and I absolutely hate it.  Right now my laptop takes far 
too long to boot and even if it didn't I wish I could suspend.

I'm actually a huge Linux fan.. I use it exclusively on my server and on 
my PC but if I get another laptop I will probably run something else on 
it.  Linux is just too annoying for that use.

	Gerhard



--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: NAK new drivers without proper power management?

[Tino Keitel]

On Sun, Feb 11, 2007 at 07:46:36 +0100, Willy Tarreau wrote:

[...]

> Many people also have Linux on their notebooks, but as a dual-boot. You
> read the word ? "dual-boot". It means that they cleanly shutdown their
> system every time they don't use it anymore, and they won't know what
> OS they'll use next time.

I can suspend to disk my Mac mini, reboot into MacOS X, shutdown, and
then resume in Linux. I also did this with APM suspend to disk support
on my ThinkPad some years ago, using Linux and Windows.

So, dualboot and suspend support isn't mutual exclusive. This is only
the case if suspend is limited to suspend to RAM.

Regards,
Tino

Re: NAK new drivers without proper power management?

[Pavel Machek]

Hi!

> > "If the device requires that, implement .suspend and .resume or at least
>                                                                   ^^^^^^^^
> > define .suspend that will always return -ENOSYS (then people will know they
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > whether or not the device requires .suspend and .resume, define .suspend that
>                                                            ^^^^^^^^^^^^^^^^^^^^
> > will always return -ENOSYS."
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Can't the upper layer just assume -ENOSYS if .resume/.suspend is NULL?
> It's nicer if you don't have to implement dummy functions at all.

Unfortunately, drivers currently assume "NULL == nothing is needed",
so we'd have t do big search & replace... 
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: NAK new drivers without proper power management?

[Geert Uytterhoeven]

On Mon, 12 Feb 2007, Pavel Machek wrote:
> > > "If the device requires that, implement .suspend and .resume or at least
> >                                                                   ^^^^^^^^
> > > define .suspend that will always return -ENOSYS (then people will know they
> >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > > whether or not the device requires .suspend and .resume, define .suspend that
> >                                                            ^^^^^^^^^^^^^^^^^^^^
> > > will always return -ENOSYS."
> >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Can't the upper layer just assume -ENOSYS if .resume/.suspend is NULL?
> > It's nicer if you don't have to implement dummy functions at all.
> 
> Unfortunately, drivers currently assume "NULL == nothing is needed",
> so we'd have t do big search & replace... 

Which means you also cannot easily keep track of which driver supports
suspend/resume and which doesn't, as there will always be drivers where a
missing suspend/resume function is correct.

Wouldn't it be more sensible to have

    .suspend = suspend_nothing_to_do

instead, and reserve NULL for `not yet implemented'?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: NAK new drivers without proper power management?

[Pavel Machek]

Hi!

> > > > > Neither am I. I'm just asking that new drivers have power management as
> > > > > standard.
> > >
> > > > What if the hardware doesn't support power management ?
> > >
> > > You would still want to do the cleanup and configuration that you'd do
> > > for module load/unload.
> > >
> > By adding dummy functions, wouldn't that just look awkward ?
> 
> If all you need to do is say 'I don't need to do anything' and we have a
> shared function that does that, all we're talking about doing is adding
> to your struct pci_device (or whatever)
> 
> .resume = generic_empty_resume;
> 
> To me at least, that doesn't look awkward, and says cleanly and clearly
> that you've checked things over and decided you know what's required.

Actually, I'd like it to be

.resume = generic_empty_resume; /* Explain, why your driver needs no
				   resume */

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: NAK new drivers without proper power management?

[Pavel Machek]

Hi!

> > > > "If the device requires that, implement .suspend and .resume or at least
> > >                                                                   ^^^^^^^^
> > > > define .suspend that will always return -ENOSYS (then people will know they
> > >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > > > whether or not the device requires .suspend and .resume, define .suspend that
> > >                                                            ^^^^^^^^^^^^^^^^^^^^
> > > > will always return -ENOSYS."
> > >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > Can't the upper layer just assume -ENOSYS if .resume/.suspend is NULL?
> > > It's nicer if you don't have to implement dummy functions at all.
> > 
> > Unfortunately, drivers currently assume "NULL == nothing is needed",
> > so we'd have t do big search & replace... 
> 
> Which means you also cannot easily keep track of which driver supports
> suspend/resume and which doesn't, as there will always be drivers where a
> missing suspend/resume function is correct.
> 
> Wouldn't it be more sensible to have
> 
>     .suspend = suspend_nothing_to_do
> 
> instead, and reserve NULL for `not yet implemented'?

It would be. Patch would be welcome :-).
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

On Monday, 12 February 2007 05:08, Nigel Cunningham wrote:
> Howdy!
> 
> On Mon, 2007-02-12 at 01:10 +0100, Tilman Schmidt wrote:
> > Hi,
> > 
> > Am 11.02.2007 23:37 schrieb Nigel Cunningham:
> > > On Sun, 2007-02-11 at 00:45 +0100, Tilman Schmidt wrote:
> > >> Am 10.02.2007 23:37 schrieb Nigel Cunningham:
> > >>> If your device requires power management, and you know it requires power
> > >>> management, why not just implement power management? [...]
> > >> Like it or not, power management is far from trivial, and people
> > >> writing device drivers have limited resources. [...]
> > > It's not that complex. All we're really talking about is a bit of extra
> > > code to cleanup and configure hardware state; things that the driver
> > > author already knows how to do. S3 might require a bit more
> > > initialisation if firmware needs to be reloaded or more extensive
> > > configuration needs to be done, but if there's firmware to be loaded,
> > > there is a reasonably good probability that we loaded it from Linux to
> > > start with anyway.
> > 
> > You are assuming a perfect world where driver authors have complete
> > knowledge of their devices. In reality, many drivers (including
> > those I have the mixed pleasure of maintaining) are based at least
> > in part on reverse engineering, and managing power states may well
> > fall into the domain of things not yet sufficiently reverse
> > engineered.
> 
> Nope. I'm assuming that the driver author knows what needs to be done to
> get the driver out of whatever state the BIOS puts it in to start with,
> and into an operational state, and that they therefore also know what
> needs to be done to take it out of the operational state again. I'm
> admitting that there's also another state - the post suspend-to-ram
> driver state - that they may not know how to deal with. But for
> suspend-to-disk, if you know how to get the driver to work in the first
> place, you know enough to stop it working (.suspend) and start it up
> again (.resume) for the hibernate case at least.

We're talking about _both_ the STR and STD.  The drivers that have problems
with the STR cannot be regarded as suspend/resume-safe IMO.

> I'm not assuming that you know enough to be able to put the driver into
> a low state and get it out again. This is definitely preferable, and at
> least possibly essential for suspend to ram, but for some unknown reason
> I'm quite hibernation focused, and for that, just the above is
> sufficient.

Please take the STR into consideration too.  After all we use the same
suspend/resume code for both STD and STR so it should work with both.  If it
doesn't work with one of them, we have a problem.

> > >> Also, in your argument you neglected a few cases:
> > >> - What if my device does not require power management?
> > > 
> > > Then you as a generic routine that does nothing but return success
> > > (potentially shared with other drivers that are in the same situation).
> > 
> > But if I just write an empty routine like that I open myself up to
> > criticism along the lines of "writing dummy routines just in order
> > to shut up kernel warnings". BTDT.
> 
> Well, it might not be completely empty. I think someone already pointed
> out that there's a minimal workset for the pci bus that pci drivers
> would want to invoke. But we wouldn't (rightly) accuse you of such
> things if we decided that the policy was "Every driver ought to have a
> resume routine, even if it's just a minimal I-just-work route".

I'm still thinking that would be wasteful.  I think there are more drivers that
work than there are drivers that don't work.

> > >> - What if I don't know whether my device requires power management?
> > > 
> > > The questions are straight forward: Is there hardware state that needs
> > > to be configured if you've just booted the computer and nothing else has
> > > touched it? If so, that needs to be done in a resume method. Do you need
> > > to clean up state prior to doing the things in the resume method, or
> > > otherwise do things to quiesce the driver? If so, they will need to be
> > > done in the suspend method. The result will be roughly similar to what
> > > you do for module load/unload, except maybe less complete in some cases.
> > 
> > I don't doubt your basic assessment. However it doesn't translate that
> > easily into a real implementation. In my case, I maintain a USB driver,
> > so I have to deal with USB specifics of suspend/resume which happen not
> > to be that well documented. My driver provides an isdn4linux device but
> > isdn4linux knows nothing about suspend/resume so I am on my own on how
> > to reconcile the two. The device itself, though in turn far from trivial,
> > is actually the least of my worries.
> 
> Mmm, so that's a case where we need to prod those who write
> documentation and bus support first. You're probably closer! :)

Actually, the lack of documentation is a major problem that we all should
try to fix in the first place.  Unfortunately the code has been recently
changing quite often, so that's difficult.

Greetings,
Rafael

Re: NAK new drivers without proper power management?

[Willy Tarreau]

On Mon, Feb 12, 2007 at 07:59:40AM -0500, Gerhard Mack wrote:
> On Sun, 11 Feb 2007, Willy Tarreau wrote:
> 
> > On Sun, Feb 11, 2007 at 09:37:06AM +1100, Nigel Cunningham wrote:
> > > On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote:
> > 
> > Many people also have Linux on their notebooks, but as a dual-boot. You
> > read the word ? "dual-boot". It means that they cleanly shutdown their
> > system every time they don't use it anymore, and they won't know what
> > OS they'll use next time.
> 
> Please tell me your joking.  Linux' crappy suspend support is a common 
> reason people give me for not wanting Linux anywhere near their laptops.  

No, I'm not kidding. The most annoyed ones are those who don't have serial
ports and who need those annoying USB adapters. But fortunately, not all
of them need to access router consoles :-)

> I have a single boot laptop that's somewhat of a mobile debugging station 
> that needs Linux and I absolutely hate it.  Right now my laptop takes far 
> too long to boot and even if it didn't I wish I could suspend.

Probably that you got the wrong laptop. If you buy an ultra-thin with highly
proprietary hardware, it may be hard. But if you choose in profesionnal ranges,
there is rarely any problem. I have a compaq nc8000 on which everything works
fine, and it boots in about 20 seconds. Other people I know have Toshibas,
NECs, Dells and IBMs and are happy with them. My previous VAIO was a dirty
crap that I would never recommend to anybody though.

> I'm actually a huge Linux fan.. I use it exclusively on my server and on 
> my PC but if I get another laptop I will probably run something else on 
> it.  Linux is just too annoying for that use.

Everyone has different needs, that's all.

Sorry, but I fell like we're becoming a bit off-topic here.

Regards,
Willy

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

On Monday, 12 February 2007 17:52, Pavel Machek wrote:
> Hi!
> 
> > > > > > Neither am I. I'm just asking that new drivers have power management as
> > > > > > standard.
> > > >
> > > > > What if the hardware doesn't support power management ?
> > > >
> > > > You would still want to do the cleanup and configuration that you'd do
> > > > for module load/unload.
> > > >
> > > By adding dummy functions, wouldn't that just look awkward ?
> > 
> > If all you need to do is say 'I don't need to do anything' and we have a
> > shared function that does that, all we're talking about doing is adding
> > to your struct pci_device (or whatever)
> > 
> > .resume = generic_empty_resume;
> > 
> > To me at least, that doesn't look awkward, and says cleanly and clearly
> > that you've checked things over and decided you know what's required.
> 
> Actually, I'd like it to be
> 
> .resume = generic_empty_resume; /* Explain, why your driver needs no
> 				   resume */

Okay, but we can't define an empty .resume(), because, for example, the PCI's
generic suspend/resume won't be called.

I think we can introduce a "pm_safe" flag that will indicate if the driver
handles suspend/resume correctly.  If we do it, we can flag all of the drivers
currently in the tree as "pm_safe" unless we know that they aren't.  Next,
we can convert the core to fail the suspend for any driver that is not flagged
as "pm_safe".  But I think that will take time.

In the meantime, I'd like to ask the authors of new drivers to define
error-returning .suspend() if they don't intend to define "real" .suspend()
and .resume() for now.  When we are ready with the conversion, we'll be able
to drop the error-returning .suspend()s and clear "pm_safe" for them.

Greetings,
Rafael

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

Hi.

On Mon, 2007-02-12 at 16:57 +0100, Geert Uytterhoeven wrote:
> On Mon, 12 Feb 2007, Pavel Machek wrote:
> > > Can't the upper layer just assume -ENOSYS if .resume/.suspend is NULL?
> > > It's nicer if you don't have to implement dummy functions at all.
> > 
> > Unfortunately, drivers currently assume "NULL == nothing is needed",
> > so we'd have t do big search & replace... 
> 
> Which means you also cannot easily keep track of which driver supports
> suspend/resume and which doesn't, as there will always be drivers where a
> missing suspend/resume function is correct.
> 
> Wouldn't it be more sensible to have
> 
>     .suspend = suspend_nothing_to_do
> 
> instead, and reserve NULL for `not yet implemented'?

Agreed.

Regards,

Nigel

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

On Monday, 12 February 2007 13:59, Gerhard Mack wrote:
> On Sun, 11 Feb 2007, Willy Tarreau wrote:
> 
> > On Sun, Feb 11, 2007 at 09:37:06AM +1100, Nigel Cunningham wrote:
> > > On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote:
> > 
> > Many people also have Linux on their notebooks, but as a dual-boot. You
> > read the word ? "dual-boot". It means that they cleanly shutdown their
> > system every time they don't use it anymore, and they won't know what
> > OS they'll use next time.
> 
> Please tell me your joking.  Linux' crappy suspend support is a common 
> reason people give me for not wanting Linux anywhere near their laptops.  
> 
> I have a single boot laptop that's somewhat of a mobile debugging station 
> that needs Linux and I absolutely hate it.  Right now my laptop takes far 
> too long to boot and even if it didn't I wish I could suspend.

When did you try last time?

Rafael

Re: NAK new drivers without proper power management?

[Pavel Machek]

Hi!

> > > If all you need to do is say 'I don't need to do anything' and we have a
> > > shared function that does that, all we're talking about doing is adding
> > > to your struct pci_device (or whatever)
> > > 
> > > .resume = generic_empty_resume;
> > > 
> > > To me at least, that doesn't look awkward, and says cleanly and clearly
> > > that you've checked things over and decided you know what's required.
> > 
> > Actually, I'd like it to be
> > 
> > .resume = generic_empty_resume; /* Explain, why your driver needs no
> > 				   resume */
> 
> Okay, but we can't define an empty .resume(), because, for example, the PCI's
> generic suspend/resume won't be called.

PCI drivers should just do .resume = pci_generic_resume, explicitely.

> In the meantime, I'd like to ask the authors of new drivers to define
> error-returning .suspend() if they don't intend to define "real" .suspend()
> and .resume() for now.  When we are ready with the conversion, we'll be able
> to drop the error-returning .suspend()s and clear "pm_safe" for them.

Yes... please.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

On Monday, 12 February 2007 21:58, Pavel Machek wrote:
> Hi!
> 
> > > > If all you need to do is say 'I don't need to do anything' and we have a
> > > > shared function that does that, all we're talking about doing is adding
> > > > to your struct pci_device (or whatever)
> > > > 
> > > > .resume = generic_empty_resume;
> > > > 
> > > > To me at least, that doesn't look awkward, and says cleanly and clearly
> > > > that you've checked things over and decided you know what's required.
> > > 
> > > Actually, I'd like it to be
> > > 
> > > .resume = generic_empty_resume; /* Explain, why your driver needs no
> > > 				   resume */
> > 
> > Okay, but we can't define an empty .resume(), because, for example, the PCI's
> > generic suspend/resume won't be called.
> 
> PCI drivers should just do .resume = pci_generic_resume, explicitely.

Well, I generally agree, but I think the idea with the "pm_safe" flag has some
advantages.  For example, the drivers that do deffine .suspend() and .resume()
which don't work correctly could be flagged as not "pm_safe" until the problems
are fixed.

Greetings,
Rafael

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

Hi.

On Mon, 2007-02-12 at 22:01 +0100, Rafael J. Wysocki wrote:
> On Monday, 12 February 2007 21:58, Pavel Machek wrote:
> > Hi!
> > 
> > > > > If all you need to do is say 'I don't need to do anything' and we have a
> > > > > shared function that does that, all we're talking about doing is adding
> > > > > to your struct pci_device (or whatever)
> > > > > 
> > > > > .resume = generic_empty_resume;
> > > > > 
> > > > > To me at least, that doesn't look awkward, and says cleanly and clearly
> > > > > that you've checked things over and decided you know what's required.
> > > > 
> > > > Actually, I'd like it to be
> > > > 
> > > > .resume = generic_empty_resume; /* Explain, why your driver needs no
> > > > 				   resume */
> > > 
> > > Okay, but we can't define an empty .resume(), because, for example, the PCI's
> > > generic suspend/resume won't be called.
> > 
> > PCI drivers should just do .resume = pci_generic_resume, explicitely.
> 
> Well, I generally agree, but I think the idea with the "pm_safe" flag has some
> advantages.  For example, the drivers that do deffine .suspend() and .resume()
> which don't work correctly could be flagged as not "pm_safe" until the problems
> are fixed.

Oooh. Now I like that idea. Are you thinking of a document in
Documentation/power that describes why pm_safe is off, or comments in
the code itself?

Regards,

Nigel

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

On Monday, 12 February 2007 22:24, Nigel Cunningham wrote:
> Hi.
> 
> On Mon, 2007-02-12 at 22:01 +0100, Rafael J. Wysocki wrote:
> > On Monday, 12 February 2007 21:58, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > > > If all you need to do is say 'I don't need to do anything' and we have a
> > > > > > shared function that does that, all we're talking about doing is adding
> > > > > > to your struct pci_device (or whatever)
> > > > > > 
> > > > > > .resume = generic_empty_resume;
> > > > > > 
> > > > > > To me at least, that doesn't look awkward, and says cleanly and clearly
> > > > > > that you've checked things over and decided you know what's required.
> > > > > 
> > > > > Actually, I'd like it to be
> > > > > 
> > > > > .resume = generic_empty_resume; /* Explain, why your driver needs no
> > > > > 				   resume */
> > > > 
> > > > Okay, but we can't define an empty .resume(), because, for example, the PCI's
> > > > generic suspend/resume won't be called.
> > > 
> > > PCI drivers should just do .resume = pci_generic_resume, explicitely.
> > 
> > Well, I generally agree, but I think the idea with the "pm_safe" flag has some
> > advantages.  For example, the drivers that do define .suspend() and .resume()
> > which don't work correctly could be flagged as not "pm_safe" until the problems
> > are fixed.
> 
> Oooh. Now I like that idea. Are you thinking of a document in
> Documentation/power that describes why pm_safe is off, or comments in
> the code itself?

I think the code should be commented in the first place.  Additionally, we can
create a file or a directory under Documentation/power for documenting more
complicated cases, if necessary.

Greetings,
Rafael

Re: NAK new drivers without proper power management?

[Nigel Cunningham]

Hi.

On Mon, 2007-02-12 at 21:06 +0100, Rafael J. Wysocki wrote:
> On Monday, 12 February 2007 05:08, Nigel Cunningham wrote:
> > Nope. I'm assuming that the driver author knows what needs to be done to
> > get the driver out of whatever state the BIOS puts it in to start with,
> > and into an operational state, and that they therefore also know what
> > needs to be done to take it out of the operational state again. I'm
> > admitting that there's also another state - the post suspend-to-ram
> > driver state - that they may not know how to deal with. But for
> > suspend-to-disk, if you know how to get the driver to work in the first
> > place, you know enough to stop it working (.suspend) and start it up
> > again (.resume) for the hibernate case at least.
> 
> We're talking about _both_ the STR and STD.  The drivers that have problems
> with the STR cannot be regarded as suspend/resume-safe IMO.

Yeah, I'm not disagreeing at all. I'm just admitting my bias toward the
bit I concentrate on more.

[...]

> > Mmm, so that's a case where we need to prod those who write
> > documentation and bus support first. You're probably closer! :)
> 
> Actually, the lack of documentation is a major problem that we all should
> try to fix in the first place.  Unfortunately the code has been recently
> changing quite often, so that's difficult.

Yeah.

Nigel

Re: NAK new drivers without proper power management?

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

Rafael J. Wysocki schrieb:
> I think we can introduce a "pm_safe" flag that will indicate if the driver
> handles suspend/resume correctly.  If we do it, we can flag all of the drivers
> currently in the tree as "pm_safe" unless we know that they aren't.  Next,
> we can convert the core to fail the suspend for any driver that is not flagged
> as "pm_safe".  But I think that will take time.

Why a new flag? IMHO it would be both more readable and more efficient
to create a pm_generic_nosuspend() function which does "return -ENOSYS",
and set that as the .suspend method on drivers known to break
suspend/resume. New drivers should either have .suspend and .resume
methods of their own or set .suspend = pm_generic_nosuspend.

That way, NULL .suspend/.resume methods retain their current semantics
("don't know whether suspend would work, never thought about it"),
error-returning ones would clearly signal "cannot suspend safely", and
success-returning ones would equally clearly signal "suspend works ok".
(Bugs nonwithstanding.)

There could then be a policy parameter (Kconfig selectable to start)
to abort suspend when encountering a driver without .suspend/.resume
methods, or to proceed with a warning message.

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: NAK new drivers without proper power management?

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

Geert Uytterhoeven schrieb:
> On Mon, 12 Feb 2007, Pavel Machek wrote:

>> > Can't the upper layer just assume -ENOSYS if .resume/.suspend is NULL?
>> > It's nicer if you don't have to implement dummy functions at all.
>> 
>> Unfortunately, drivers currently assume "NULL == nothing is needed",

More often than not they assume nothing of the kind.

>> so we'd have t do big search & replace... 
> 
> Which means you also cannot easily keep track of which driver supports
> suspend/resume and which doesn't, as there will always be drivers where a
> missing suspend/resume function is correct.

I think those are rare exceptions. They could and should be
asked to make this statement explicit, as you propose:

> Wouldn't it be more sensible to have
> 
>     .suspend = suspend_nothing_to_do
> 
> instead, and reserve NULL for `not yet implemented'?

NULL is already taken for 'don't know'. So *two* new values
are needed, one for "nothing to do" and one for "not supported".

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: NAK new drivers without proper power management?

[Brad Campbell]

Willy Tarreau wrote:

> Probably that you got the wrong laptop. If you buy an ultra-thin with highly
> proprietary hardware, it may be hard. But if you choose in profesionnal ranges,
> there is rarely any problem. I have a compaq nc8000 on which everything works
> fine, and it boots in about 20 seconds. Other people I know have Toshibas,
> NECs, Dells and IBMs and are happy with them. My previous VAIO was a dirty
> crap that I would never recommend to anybody though.

Whereas my "ultru-thin" VAIO works perfectly with both S2D and S2R and the only thing I have some 
difficulty with is the SD reader. Would not hesitate to recommend it to anyone.

I often hibernate linux to boot into a hibernated windows session, then go back the other way as 
required, and my machine might do 80-100 "suspend2both" sessions a month between reboots. 30-40 
seconds to suspend mostly (1.5GB of RAM) and about 15 to come back. That's what I call highly useful.

Different strokes and all that I guess..

Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: NAK new drivers without proper power management?

[Mark Lord]

Nigel Cunningham wrote:
> On Sun, 2007-02-11 at 01:27 +0100, Rafael J. Wysocki wrote:
>> Plus:
>> - What if I'm planning to implement the power managemet, but not just right
>> now?
> 
> Why not right now?

LKML is much more receptive to drivers that follow
the "release early, release often" mantra.

Which means we really have to be more accomodating of
drivers that start out simple, and then gain all of the
non-essential capabilities gradually over time.

Simple observation here shows much more hostility :)
to drivers that are simply "presented" as a complete whole.
Often for good reason -- starting out with a framework
and then adding the rest bit by bit allows for much better
peer review and feedback.

And not all devices / situations need power management,
and lack of documentation on the hardware often prevents
us from implementing it at the outset.

Cheers

Re: NAK new drivers without proper power management?

[Christoph Hellwig]

On Tue, Feb 13, 2007 at 10:55:18AM -0500, Mark Lord wrote:
> LKML is much more receptive to drivers that follow
> the "release early, release often" mantra.

Exactly.

> Which means we really have to be more accomodating of
> drivers that start out simple, and then gain all of the
> non-essential capabilities gradually over time.

We usually are, the endless flamewar lurkers might not :)
> 
> Simple observation here shows much more hostility :)
> to drivers that are simply "presented" as a complete whole.
> Often for good reason -- starting out with a framework
> and then adding the rest bit by bit allows for much better
> peer review and feedback.

*nod*

> And not all devices / situations need power management,
> and lack of documentation on the hardware often prevents
> us from implementing it at the outset.

*nod*

So can be use Mark's excellent post as closing of this
utterly useless thread and go on to real work now?

Re: NAK new drivers without proper power management?

[Rafael J. Wysocki]

On Tuesday, 13 February 2007 10:42, Tilman Schmidt wrote:
> Rafael J. Wysocki schrieb:
> > I think we can introduce a "pm_safe" flag that will indicate if the driver
> > handles suspend/resume correctly.  If we do it, we can flag all of the drivers
> > currently in the tree as "pm_safe" unless we know that they aren't.  Next,
> > we can convert the core to fail the suspend for any driver that is not flagged
> > as "pm_safe".  But I think that will take time.
> 
> Why a new flag?

For example, there are drivers that define .suspend() and .resume() which
do not work correctly and we can use the flag to mark them.

> IMHO it would be both more readable and more efficient 
> to create a pm_generic_nosuspend() function which does "return -ENOSYS",
> and set that as the .suspend method on drivers known to break
> suspend/resume. New drivers should either have .suspend and .resume
> methods of their own or set .suspend = pm_generic_nosuspend.

This is quite similar to what we are trying to do now: ask driver authors to
define .suspend that will return -ENOSYS if they can't ensure that the driver
will handle the suspend and resume correctly.

> That way, NULL .suspend/.resume methods retain their current semantics
> ("don't know whether suspend would work, never thought about it"),

I think this convention is unfortunate.  The default should be to fail the
suspend if there's no .suspend defined, IMO.  Still, it's hard to change now.

> error-returning ones would clearly signal "cannot suspend safely", and
> success-returning ones would equally clearly signal "suspend works ok".
> (Bugs nonwithstanding.)
> 
> There could then be a policy parameter (Kconfig selectable to start)
> to abort suspend when encountering a driver without .suspend/.resume
> methods, or to proceed with a warning message.

I think there are many drivers without .suspend and .resume already in the
tree, so that wouldn't be practical.

Greetings,
Rafael

Re: NAK new drivers without proper power management?

[Stefan Richter]

Rafael J. Wysocki wrote:
>> Why a new flag?
> 
> For example, there are drivers that define .suspend() and .resume() which
> do not work correctly and we can use the flag to mark them.

Depending on how serious the problems with these .suspend/.resume()s
are, you could also put a printk in them or #if 0 bad_code #else return
-ENOSYS #endif around them.

Suspend/resume semantics for ISDN drivers (was: NAK new drivers without proper power management?)

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

Ok, I've thought some more but I still don't know ...

On 12.02.2007 01:10 I wrote:
> I don't doubt your basic assessment. However it doesn't translate that
> easily into a real implementation. In my case, I maintain a USB driver,
> so I have to deal with USB specifics of suspend/resume which happen not
> to be that well documented. My driver provides an isdn4linux device but
> isdn4linux knows nothing about suspend/resume so I am on my own on how
> to reconcile the two. The device itself, though in turn far from trivial,
> is actually the least of my worries.

So, how *should* an isdn4linux driver handle a request to suspend?
Specifically, if there are active connections, should it try to
shut them down in an orderly fashion (which might imply some delays
waiting for the remote station to acknowledge, etc.)? Should it kill
them abruptly (as for a USB unplug event)? Or should it just refuse
to suspend while a connection is still active?

Thanks for any insights,
Tilman

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: Suspend/resume semantics for ISDN drivers (was: NAK new drivers without proper power management?)

[Rafael J. Wysocki]

On Saturday, 3 March 2007 23:48, Tilman Schmidt wrote:
> Ok, I've thought some more but I still don't know ...
> 
> On 12.02.2007 01:10 I wrote:
> > I don't doubt your basic assessment. However it doesn't translate that
> > easily into a real implementation. In my case, I maintain a USB driver,
> > so I have to deal with USB specifics of suspend/resume which happen not
> > to be that well documented. My driver provides an isdn4linux device but
> > isdn4linux knows nothing about suspend/resume so I am on my own on how
> > to reconcile the two. The device itself, though in turn far from trivial,
> > is actually the least of my worries.
> 
> So, how *should* an isdn4linux driver handle a request to suspend?
> Specifically, if there are active connections, should it try to
> shut them down in an orderly fashion (which might imply some delays
> waiting for the remote station to acknowledge, etc.)? Should it kill
> them abruptly (as for a USB unplug event)? Or should it just refuse
> to suspend while a connection is still active?

I think that refusing to suspend wouldn't be a good approach (think of an
emergency suspend when the battery is running low).

Probably the closing of connections would be the nicest thing from the
user's point of view.

Greetings,
Rafael

Re: Suspend/resume semantics for ISDN drivers (was: NAK new drivers without proper power management?)

[Pavel Machek]

Hi!

> > On 12.02.2007 01:10 I wrote:
> > > I don't doubt your basic assessment. However it doesn't translate that
> > > easily into a real implementation. In my case, I maintain a USB driver,
> > > so I have to deal with USB specifics of suspend/resume which happen not
> > > to be that well documented. My driver provides an isdn4linux device but
> > > isdn4linux knows nothing about suspend/resume so I am on my own on how
> > > to reconcile the two. The device itself, though in turn far from trivial,
> > > is actually the least of my worries.
> > 
> > So, how *should* an isdn4linux driver handle a request to suspend?
> > Specifically, if there are active connections, should it try to
> > shut them down in an orderly fashion (which might imply some delays
> > waiting for the remote station to acknowledge, etc.)? Should it kill
> > them abruptly (as for a USB unplug event)? Or should it just refuse
> > to suspend while a connection is still active?
> 
> I think that refusing to suspend wouldn't be a good approach (think of an
> emergency suspend when the battery is running low).
> 
> Probably the closing of connections would be the nicest thing from the
> user's point of view.

It depends on "how long does connection close take". If it is more
than few seconds, kill them abruptly.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html