PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1

[Tony Lindgren]

* Ulf Hansson <ulf.hansson at linaro.org> [160203 10:38]:
> On 3 February 2016 at 19:28, Tony Lindgren <tony at atomide.com> wrote:
> > * Ulf Hansson <ulf.hansson at linaro.org> [160203 10:03]:
> >>
> >> One more thing though. I just realized that you have yet another issue
> >> to consider going for the approach fixing *only* drivers.
> >>
> >> Let me summarize it here:
> >>
> >> If userspace has prevented runtime PM (pm_runtime_forbid()) when a
> >> driver becomes unbound, the driver will not be able to suspend the
> >> device by using any of the pm_runtime_suspend() APIs, as the usage
> >> count is isn't zero.
> >>
> >> As pm_runtime_reinit() is invoked as part of the driver unbind
> >> sequence, the runtime PM status goes out of sync. A following driver
> >> rebind will then trigger the warning when the PM domain's
> >> ->runtime_resume() callback gets invoked. Again, forever preventing
> >> the device from being runtime suspended.
> >
> > Hmm yeah that's a good point.
> >
> >> How do you intend to solve this case?
> >> I guess there are two options, pick up the patch I posted for omap
> >> hwmod or make use of pm_runtime_force_suspend() in the driver.
> >
> > My gut feeling right now is we should just have
> > BUS_NOTIFY_UNBIND_DRIVER shut down the device on the interconnect
> > automatically as it's unused after the driver has unloaded :)
> 
> BUS_NOTIFY_UNBIND_DRIVER is sent prior the ->remove() callbacks is
> invoked from driver core.
> So if the driver requires to do a pm_runtime_get_sync() during
> ->remove() callback, this won't work.
> 
> BUS_NOTIFY_UNBOUND_DRIVER may work though.

Right sorry that's what I meant. Naturally we can't do it before
remove :)

I'll take a look.

Tony