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

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

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.

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
===================================================================
@@ -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"))

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

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

thanks,

greg k-h

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