linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux PM <linux-pm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	USB list <linux-usb@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Kishon Vijay Abraham I <kishon@ti.com>
Subject: RE: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()
Date: Tue, 5 Dec 2017 10:03:15 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1712050958090.1416-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <TY1PR06MB0992214C75585618A1400A1CD83D0@TY1PR06MB0992.apcprd06.prod.outlook.com>

On Tue, 5 Dec 2017, Yoshihiro Shimoda wrote:

> Hi,
> 
> > From: Ulf Hansson, Sent: Monday, December 4, 2017 7:41 PM
> > 
> > On 1 December 2017 at 12:03, Yoshihiro Shimoda
> > <yoshihiro.shimoda.uh@renesas.com> wrote:
> <snip>
> > > Sure! I tested your patch, and then the following message disappeared!
> > >
> > >    Enabling runtime PM for inactive device (ee080200.usb-phy) with active children
> > 
> > Great, that confirms my theory.
> > 
> > I will re-work the patch and re-post it to see what people thinks about it.
> 
> Thank you!
> 
> > >
> > > However, the following message still exists.
> > >
> > >    Enabling runtime PM for inactive device (ee080000.usb) with active children
> > >
> > > So, I guess ohci-platform.c also has similar issue.
> > 
> > Yes, very likely!
> > 
> > However, I need some more time to look into this to be able to suggest
> > a solution.
> 
> I found a solution and sent a report as below:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1551146.html
> 
> What do you think about using pm_runtime_forbid()?

In general, drivers should not use pm_runtime_forbid().

It is meant for use by userspace, through the /sys/.../power/control 
file.  Drivers cannot rely on the result of calling pm_runtime_forbid() 
or pm_runtime_allow(), because the user can change it at any time.

If you really want to prevent the OHCI controller from going into 
runtime suspend, the proper approach is to call pm_runtime_get() in the 
probe routine and pm_runtime_put() in the release routine.  However, 
this will waste energy because it will force the controller to remain 
at full power even when no active devices are attached.

In this case, there probably is a better to solution to your problem 
(such as fixing the runtime PM support in the phy driver).

Alan Stern

  reply	other threads:[~2017-12-05 15:03 UTC|newest]

Thread overview: 30+ 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
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 15:03                         ` Alan Stern [this message]
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=Pine.LNX.4.44L0.1712050958090.1416-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kishon@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=ulf.hansson@linaro.org \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).