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

[Jeff LaBundy <jeff@labundy.com>]

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