Re: [PATCH] driver core: Ensure proper suspend/resume ordering

From: Rafael J. Wysocki
Date: Wed Sep 16 2015 - 22:04:39 EST


On Thu, Sep 17, 2015 at 2:27 AM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
> On Wednesday, September 16, 2015 03:22:37 PM Alan Stern wrote:
>> On Wed, 16 Sep 2015, Thierry Reding wrote:

[cut]

>
> And I'm wondering if and how that is related to runtime PM? It only
> covers the system sleep transitions case, but who's responsible for the
> runtime PM part? Device drivers?
>

Which reminds me of something we all seem to be forgetting about:
there is asynchronous suspend and resume which may cause suspend and
resume callbacks of devices to be executed in an order that is
different from the dpm_list order. In those cases the device that
depends on another one has to explicitly wait for the other one to
complete its callback in the current phase of the transition.

While correct ordering of dpm_list is essential for this to work too,
it by no means is sufficient, so in the end the driver having a
dependency needs to know about it and act on it as needed (or we need
an alternative mechanism that will do that automatically, but I'm not
sure what that may be).

Actually, I was thinking about adding something like pm_get() for this
purpose that will do pm_runtime_get_sync() on the target and will
ensure that the right things will happen during system suspend/resume
in addition to that, including reordering dpm_list if necessary.
Plus, of course, the complementary pm_put().

With something like that available, there should be no need to reorder
dpm_list anywhere else. The problem with this approach is that the
reordering becomes quite complicated then, as it would need to move
the device itself after the target and anything that depends on it
along with it and tracking those dependencies becomes quite
problematic.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/