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: Wed, 15 Nov 2017 08:22:54 +0100	[thread overview]
Message-ID: <CAPDyKFoZ7wj8Cx_P1FiNxE-5qOt-_sPY6Tt1z8bmi2TPxwdF_Q@mail.gmail.com> (raw)
In-Reply-To: <5072995.lhOZmqyh0S@aspire.rjw.lan>

[...]

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

Yeah, you have a point.

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

Fair enough!

Feel free to add:
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

  reply	other threads:[~2017-11-15  7:23 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
2017-11-14  9:56       ` Ulf Hansson
2017-11-14 21:44         ` Rafael J. Wysocki
2017-11-15  7:22           ` Ulf Hansson [this message]
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=CAPDyKFoZ7wj8Cx_P1FiNxE-5qOt-_sPY6Tt1z8bmi2TPxwdF_Q@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.