All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: 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: Tue, 14 Nov 2017 10:13:29 +0100	[thread overview]
Message-ID: <CAPDyKFrzJuWVr9hmcU-S6LMMGTh2pyQcjMJc2+ky5AmctatOLQ@mail.gmail.com> (raw)
In-Reply-To: <7259587.Kcyqf0xrP6@aspire.rjw.lan>

On 13 November 2017 at 22:50, 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
> 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.

>
> 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 ...

Where and how is that guarantee made?

[...]

Kind regards
Uffe

  parent reply	other threads:[~2017-11-14  9:13 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
2017-11-14  9:13     ` Ulf Hansson [this message]
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=CAPDyKFrzJuWVr9hmcU-S6LMMGTh2pyQcjMJc2+ky5AmctatOLQ@mail.gmail.com \
    --to=ulf.hansson@linaro.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 \
    /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.