/sys/devices/.../power/state broken?

/sys/devices/.../power/state broken?

[Brice Goglin]

Hi,

I know that .../power/state files are deprecated, but I like using them
for basic testing of a driver's suspend/resume routines. Anyway, echoing
something in the .../power/state in current -git does not seem to work
anymore. For instance, the driver's suspend routine is not called
anymore  when writing 3 while it was at least in 2.6.17 and 2.6.18. And
reading the contents of the file afterwards now returns 0 while it
seemed to return 2 before.

I didn't have time to git-bisect the problem so far, I will if nobody
has any idea.

And if somebody knows what to use instead of .../power/state to test a
driver's suspend/resume, I'd be happy to hear it too. The explanation in
feature-removal-schedule.txt did not help a lot, neither did the thread
I found on linux-pm :)

thanks,
Brice

Re: /sys/devices/.../power/state broken?

[Alan Stern]

On Tue, 12 Dec 2006, Brice Goglin wrote:

> Hi,
> 
> I know that .../power/state files are deprecated, but I like using them
> for basic testing of a driver's suspend/resume routines. Anyway, echoing
> something in the .../power/state in current -git does not seem to work
> anymore.

It does work, but the results depend on the device you want to suspend.  
For instance, USB devices have no problem at all.  PCI devices will ignore
your writes because .../power/state can't handle the new multi-stage
suspend and resume mechanism.

I've been using the patch below to force my tests to work.  The fact 
remains, this way of doing things won't be valid much longer.

>  For instance, the driver's suspend routine is not called
> anymore  when writing 3 while it was at least in 2.6.17 and 2.6.18. And
> reading the contents of the file afterwards now returns 0 while it
> seemed to return 2 before.
> 
> I didn't have time to git-bisect the problem so far, I will if nobody
> has any idea.
> 
> And if somebody knows what to use instead of .../power/state to test a
> driver's suspend/resume, I'd be happy to hear it too. The explanation in
> feature-removal-schedule.txt did not help a lot, neither did the thread
> I found on linux-pm :)

There is no general-purpose replacement.  Probably each bus will end up 
implementing its own special-purpose sysfs interface for suspend/resume 
(or not, as the case may be).

Alan Stern


Index: usb-2.6/drivers/base/power/sysfs.c
===================================================================
--- usb-2.6.orig/drivers/base/power/sysfs.c
+++ usb-2.6/drivers/base/power/sysfs.c
@@ -45,10 +45,6 @@ static ssize_t state_store(struct device
 	pm_message_t state;
 	int error = -EINVAL;
 
-	/* disallow incomplete suspend sequences */
-	if (dev->bus && (dev->bus->suspend_late || dev->bus->resume_early))
-		return error;
-
 	state.event = PM_EVENT_SUSPEND;
 	/* Older apps expected to write "3" here - confused with PCI D3 */
 	if ((n == 1) && !strcmp(buf, "3"))

Re: /sys/devices/.../power/state broken?

[David Brownell]

On Tuesday 12 December 2006 7:42 am, Alan Stern wrote:
> On Tue, 12 Dec 2006, Brice Goglin wrote:
> 
> > Hi,
> > 
> > I know that .../power/state files are deprecated, but I like using them
> > for basic testing of a driver's suspend/resume routines. Anyway, echoing
> > something in the .../power/state in current -git does not seem to work
> > anymore.
> 
> It does work, but the results depend on the device you want to suspend.  
> For instance, USB devices have no problem at all.  PCI devices will ignore
> your writes because .../power/state can't handle the new multi-stage
> suspend and resume mechanism.
> 
> I've been using the patch below to force my tests to work. 

... relying on the fact that few drivers currently use the late_suspend()
or early_resume() methods.  I know one such driver is in a 2.6.20 merge
queue, but drivers using those methods are still a bit uncommon.


Speaking of those new PM methods ... Greg, I tried refreshing my
patch that uses class suspend() and resume() methods with RTCs to
adjust the system clock properly on resume.  But neither method
is getting called any more.  Did that break with the class device
changes?

- Dave

Re: /sys/devices/.../power/state broken?

[Greg KH]

On Tue, Dec 12, 2006 at 10:15:39AM -0800, David Brownell wrote:
> 
> Speaking of those new PM methods ... Greg, I tried refreshing my
> patch that uses class suspend() and resume() methods with RTCs to
> adjust the system clock properly on resume.  But neither method
> is getting called any more.  Did that break with the class device
> changes?

It shouldn't have, but to be honest, I haven't paid attention to it.

thanks,

greg k-h

Re: class suspend()/resume() broken

[David Brownell]

On Friday 15 December 2006 11:01 am, Greg KH wrote:
> On Tue, Dec 12, 2006 at 10:15:39AM -0800, David Brownell wrote:
> > 
> > Speaking of those new PM methods ... Greg, I tried refreshing my
> > patch that uses class suspend() and resume() methods with RTCs to
> > adjust the system clock properly on resume.  But neither method
> > is getting called any more.  Did that break with the class device
> > changes?
> 
> It shouldn't have, but to be honest, I haven't paid attention to it.

Well, it seems broken and, pending "git bisect", those patches are
the obvious candidate.

Maybe it's related to "dev->class" now being "optional"?  And, it
seems, null ... I'm not clear on how devices associated with two
or more classes would work, either.

In general, _using_ those class suspend()/resume() calls was kind
of painful since what's needed is the class_device, and there's no
obvious way to get from a device back to that.  That RTC patch
originally worked via some really ugly and not-generalizable code
that relied on there being only one class_device used to restore
the clock after resume, so it could just look at every device given
to those calls, and ignore it if it wasn't the one associated with
that class_device.

I have a sneaking suspicion that we're missing back-links from
devices to their associated classes, but to justify that I'd
have to dive deep into the driver model again.  :(

- Dave