All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()
Date: Mon, 13 Nov 2017 22:58:59 +0100	[thread overview]
Message-ID: <CAJZ5v0gba0g0X4u7Y3O0pbJmpgetcfAaUAZj_GK0HUQTJExYuw@mail.gmail.com> (raw)
In-Reply-To: <7259587.Kcyqf0xrP6@aspire.rjw.lan>

On Mon, Nov 13, 2017 at 10:50 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Monday, November 13, 2017 2:26:28 PM CET Ulf Hansson wrote:
>> On 12 November 2017 at 01:27, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> >
>> > 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.
>
>> 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

Actually, the parent's child_count is affected, but that doesn't matter here.

> 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.
>
> 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.
>
>> 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 ...
>
> OTOH, the runtime PM status of the children doesn't matter here, because their
> reference counters are not updated.

Thanks,
Rafael

  reply	other threads:[~2017-11-13 21:59 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-12  0:27 [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status() Rafael J. Wysocki
2017-11-13 13:26 ` Ulf Hansson
2017-11-13 21:50   ` Rafael J. Wysocki
2017-11-13 21:58     ` Rafael J. Wysocki [this message]
2017-11-14  9:13     ` Ulf Hansson
2017-11-14  9:56       ` Ulf Hansson
2017-11-14 21:44         ` Rafael J. Wysocki
2017-11-15  7:22           ` Ulf Hansson
2017-11-16  9:22 ` Johan Hovold
2017-11-16 13:57   ` Rafael J. Wysocki
2017-11-28 10:58 ` Geert Uytterhoeven
2017-11-28 12:48   ` Yoshihiro Shimoda
2017-11-28 15:06     ` Alan Stern
2017-11-29  8:21       ` Yoshihiro Shimoda
2017-11-28 17:22     ` Ulf Hansson
2017-11-29  8:21       ` Yoshihiro Shimoda
2017-11-29  9:24         ` Ulf Hansson
2017-11-29  9:43           ` Geert Uytterhoeven
2017-11-29  9:59             ` Ulf Hansson
2017-11-29 14:09               ` Geert Uytterhoeven
2017-11-30 12:51               ` Yoshihiro Shimoda
2017-12-01  9:22                 ` Ulf Hansson
2017-12-01 11:03                   ` Yoshihiro Shimoda
2017-12-01 11:54                     ` Yoshihiro Shimoda
2017-12-04 10:41                     ` Ulf Hansson
2017-12-05  3:23                       ` Yoshihiro Shimoda
2017-12-05  3:23                         ` Yoshihiro Shimoda
2017-12-05 15:03                         ` Alan Stern
2017-12-05 15:23                           ` Rafael J. Wysocki
2017-12-05 15:48                         ` Ulf Hansson
2017-11-28 14:17   ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJZ5v0gba0g0X4u7Y3O0pbJmpgetcfAaUAZj_GK0HUQTJExYuw@mail.gmail.com \
    --to=rafael@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=stern@rowland.harvard.edu \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.