Hello,
by reading kernel documentation, I was thinking that PM was excluding this possibility.
Quote from power/runtime_pm:
"The PM core does its best to reduce the probability of race conditions between the runtime PM and system suspend/resume (and hibernation) callbacks by carrying out the following operations:
* During system suspend pm_runtime_get_noresume() is called for every device right before executing the subsystem-level .prepare() callback for it and pm_runtime_barrier() is called for every device right before executing the subsystem-level .suspend() callback for it. In addition to that the PM core calls __pm_runtime_disable() with ‘false’ as the second argument for every device right before executing the subsystem-level .suspend_late() callback for it.
* During system resume pm_runtime_enable() and pm_runtime_put() are called for every device right after executing the subsystem-level .resume_early() callback and right after executing the subsystem-level .complete() callback for it, respectively"
The 2 suspend callbacks are also locking the device mutex.
But I can totally misunderstood the situation. If you can confirm if it is the case or not, that would be really helpful.
Thanks a lot,
JB
From: Andy Shevchenko <andy.shevchenko@xxxxxxxxx>
Sent: Tuesday, March 31, 2020 19:29
To: Jean-Baptiste Maneyrol <JManeyrol@xxxxxxxxxxxxxx>
Cc: linux-iio <linux-iio@xxxxxxxxxxxxxxx>; Jonathan Cameron <jic23@xxxxxxxxxx>
Subject: Re: [PATCH] iio: imu: inv_mpu6050: fix suspend/resume with runtime power
CAUTION: This email originated from outside of the organization. Please make sure the sender is who they say they are and do not click links or open attachments unless you recognize the sender and know the content is safe.
On Tue, Mar 31, 2020 at 4:39 PM Jean-Baptiste Maneyrol
<jmaneyrol@xxxxxxxxxxxxxx> wrote:
>
> Suspend/resume were not working correctly with pm runtime.
> Now suspend check if the chip is already suspended, and
> resume put runtime pm in the correct state.
>
> Fixes: 4599cac84614 ("iio: imu: inv_mpu6050: use runtime pm with autosuspend")
> Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@xxxxxxxxxxxxxx>
> + st->suspended_sensors = 0;
> + if (pm_runtime_suspended(dev)) {
> + result = 0;
> + goto out_unlock;
> + }
AFAIK this is not enough to guarantee that device *will be* suspended.
That said, in one thread you may get device in the middle of RPM
suspend, while here you are checking if it's okay or not, but after in
the other thread you will get an error and roll back to the resumed
state.
--
With Best Regards,
Andy Shevchenko
