RE: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

[Alan Stern]

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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx/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