On Tuesday, November 14, 2017 10:56:39 AM CET Ulf Hansson wrote:

On 14 November 2017 at 10:13, Ulf Hansson [off-list ref] wrote:

quoted

On 13 November 2017 at 22:50, Rafael J. Wysocki [off-list ref] wrote:

quoted

On Monday, November 13, 2017 2:26:28 PM CET Ulf Hansson wrote:

quoted

On 12 November 2017 at 01:27, Rafael J. Wysocki [off-list ref] wrote:

quoted

From: Rafael J. Wysocki <redacted>

The check for "active" children in __pm_runtime_set_status(), when
trying to set the parent device status to "suspended", doesn't
really make sense, because in fact it is not invalid to set the
status of a device with runtime PM disabled to "suspended" in any
case.  It is invalid to enable runtime PM for a device with its
status set to "suspended" while its child_count reference counter
is nonzero, but the check in __pm_runtime_set_status() doesn't
really cover that situation.

The reason to why I changed this in commit a8636c89648a ("PM /
Runtime: Don't allow to suspend a device with an active child") was
because to get a consistent behavior.

Well, it causes the function to return an error in a non-error situation,
which IMnsHO is a bug.

quoted

Because, setting the device's status to active (RPM_ACTIVE) via
__pm_runtime_set_status(), requires its parent to also be active (in
case the parent has runtime PM enabled).

No!!!

The check is in there, because the parent's usage_count is affected by that
code and incrementing it in case the parent has runtime PM enabled and is
RPM_SUSPENDED leads to an inconsistent runtime PM state of the parent.  IOW,
it would confuse the framework.

Right, I do understand the reasons *why* it is like this.

quoted

There's no such issue if the runtime PM status of a child is set to RPM_SUSPENDED.

It is all consistent without the check I'm removing and is made inconsistent
by that very check.

quoted

I would prefer to try maintain this consistency, but I also I realize
that commit a8636c89648a, should also have been checking if the parent
has runtime PM enabled (again for consistency), which it doesn't.

What about fixing that instead?

Runtime PM is *disabled* for the parent at this point, guaranteed, so there's
nothing to check, I'm afraid ...

Where and how is that guarantee made?

Oh, just realize that it should be "child" instead of "parent", in the
above reasoning. Apologize for giving the wrong argument.

So, let's me take this once again, to make it clear.

When pm_runtime_set_suspended(dev) is called, dev's child device may
still be runtime PM enabled and active.
I was suggesting to add a check for this scenario, to see if dev's
child device is runtime PM is enabled, as and additional constraint
before deciding to return an error code.

Well, that's sort of difficult to do, however, because the code would need to
walk all of the children of the device and the child power lock cannot be
acquired under the one of the parent, so it would be fragile and ugly.

The idea was to get a consistent behavior, from the
pm_runtime_set_active|suspended() APIs point of view, and not from the
runtime PM core point of view.

Yes, but the cost is high and the benefit is shallow.

The enable-time WARN() should cover the really broken cases without that
much complexity.

Thanks,
Rafael