[PATCH] PM / sysfs: Add the ability to call PM operations manually

[PATCH] PM / sysfs: Add the ability to call PM operations manually

[Jeff LaBundy]

During driver development, it's useful to be able to call a device's
suspend and resume operations for test purposes without having to
involve the rest of the PM subsystem. Such an ability would be handy
for measuring power consumption, checking interrupt function, etc.

The PM subsystem does have debug hooks for limiting the scope of
suspend or excluding devices that shouldn't suspend, but there can be
overhead in configuring these hooks that is often inconvenient during
early bring-up.

This patch introduces the pm_op_test attribute, to be used as follows
(random I2C client used as an example):

1. echo 'suspend' > /sys/bus/i2c/devices/1-0044/power/pm_op_test
2. Measure power consumption at one's leisure, check wake-up interrupt
   behavior, etc.
3. echo 'resume' > /sys/bus/i2c/devices/1-0044/power/pm_op_test

Nothing is done to check or report the device's state; as such this
new function is conservatively guarded by CONFIG_PM_ADVANCED_DEBUG.
Only suspend and resume PM operations are included for now.

Signed-off-by: Jeff LaBundy <jeff@labundy.com>
---
 drivers/base/power/sysfs.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
index c7b2481..78ee6f1 100644
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -77,6 +77,8 @@
  *	attribute is set to "enabled" by bus type code or device drivers and in
  *	that cases it should be safe to leave the default value.
  *
+ *	pm_op_test - Call one of the device's PM operations for test purposes
+ *
  *	autosuspend_delay_ms - Report/change a device's autosuspend_delay value
  *
  *	Some drivers don't want to carry out a runtime suspend as soon as a
@@ -571,6 +573,27 @@ static ssize_t async_store(struct device *dev, struct device_attribute *attr,
 
 static DEVICE_ATTR_RW(async);
 
+static const char pm_op_test_suspend[] = "suspend";
+static const char pm_op_test_resume[] = "resume";
+
+static ssize_t pm_op_test_store(struct device *dev,
+				struct device_attribute *attr,
+				const char *buf, size_t n)
+{
+	int ret;
+
+	if (sysfs_streq(buf, pm_op_test_suspend))
+		ret = pm_generic_suspend(dev);
+	else if (sysfs_streq(buf, pm_op_test_resume))
+		ret = pm_generic_resume(dev);
+	else
+		ret = -EINVAL;
+
+	return ret < 0 ? ret : n;
+}
+
+static DEVICE_ATTR_WO(pm_op_test);
+
 #endif /* CONFIG_PM_SLEEP */
 #endif /* CONFIG_PM_ADVANCED_DEBUG */
 
@@ -578,6 +601,7 @@ static struct attribute *power_attrs[] = {
 #ifdef CONFIG_PM_ADVANCED_DEBUG
 #ifdef CONFIG_PM_SLEEP
 	&dev_attr_async.attr,
+	&dev_attr_pm_op_test.attr,
 #endif
 	&dev_attr_runtime_status.attr,
 	&dev_attr_runtime_usage.attr,
-- 
2.7.4

Re: [PATCH] PM / sysfs: Add the ability to call PM operations manually

[Rafael J. Wysocki]

On Mon, Oct 12, 2020 at 2:09 AM Jeff LaBundy <jeff@labundy.com> wrote:
>
> During driver development, it's useful to be able to call a device's
> suspend and resume operations for test purposes without having to
> involve the rest of the PM subsystem. Such an ability would be handy
> for measuring power consumption, checking interrupt function, etc.
>
> The PM subsystem does have debug hooks for limiting the scope of
> suspend or excluding devices that shouldn't suspend, but there can be
> overhead in configuring these hooks that is often inconvenient during
> early bring-up.
>
> This patch introduces the pm_op_test attribute, to be used as follows
> (random I2C client used as an example):
>
> 1. echo 'suspend' > /sys/bus/i2c/devices/1-0044/power/pm_op_test
> 2. Measure power consumption at one's leisure, check wake-up interrupt
>    behavior, etc.
> 3. echo 'resume' > /sys/bus/i2c/devices/1-0044/power/pm_op_test

This is utterly incorrect.

In general, the suspend and resume callbacks specific to system-wide
PM cannot be executed in the working state of the system safely.

Thanks!

Re: [PATCH] PM / sysfs: Add the ability to call PM operations manually

[Jeff LaBundy]

Hi Rafael,

Thank you for taking a look.

On Mon, Oct 12, 2020 at 12:31:02PM +0200, Rafael J. Wysocki wrote:
> On Mon, Oct 12, 2020 at 2:09 AM Jeff LaBundy <jeff@labundy.com> wrote:
> >
> > During driver development, it's useful to be able to call a device's
> > suspend and resume operations for test purposes without having to
> > involve the rest of the PM subsystem. Such an ability would be handy
> > for measuring power consumption, checking interrupt function, etc.
> >
> > The PM subsystem does have debug hooks for limiting the scope of
> > suspend or excluding devices that shouldn't suspend, but there can be
> > overhead in configuring these hooks that is often inconvenient during
> > early bring-up.
> >
> > This patch introduces the pm_op_test attribute, to be used as follows
> > (random I2C client used as an example):
> >
> > 1. echo 'suspend' > /sys/bus/i2c/devices/1-0044/power/pm_op_test
> > 2. Measure power consumption at one's leisure, check wake-up interrupt
> >    behavior, etc.
> > 3. echo 'resume' > /sys/bus/i2c/devices/1-0044/power/pm_op_test
> 
> This is utterly incorrect.
> 
> In general, the suspend and resume callbacks specific to system-wide
> PM cannot be executed in the working state of the system safely.

I don't disagree that suspending some devices outside of PM's knowledge
can be dangerous; that's why it's presented as a debug option. But for
innocuous devices like keypads or LED controllers where all we're doing
is writing some registers to put that device in a low-power mode during
system-wide suspend, it seems OK for test purposes.

Here's an example: I need to test the register writes and sequencing
in my suspend callback. I can use pm_test to do something similar, but
by the time I've fumbled around with my oscilloscope probes or called a
co-worker to come look at my bench while the device of interest is in a
low-power state, the system has already resumed.

Furthermore a development system may have some other blocking issue that
prevents system-wide suspend from working. I talk to my current platform
with SSH and if I try to test my driver's suspend callback with pm_test,
the platform drops off the network presumably because the WLAN adapter
is suspending (and it doesn't come back, presumably because it doesn't
support runtime suspend in the first place). In many cases we need to get
a driver to a vendor faster than we can troubleshoot that problem.

Is there a way I can change the patch to make it more palatable? I'm also
happy to drop it; it has simply been handy for me to have locally so I
figured I'd share it.

> 
> Thanks!

Kind regards,
Jeff LaBundy