From: tony@atomide.com (Tony Lindgren) Date: Wed, 3 Feb 2016 10:28:28 -0800 Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1 In-Reply-To: References: <20160202030533.GT19432@atomide.com> <20160202163536.GU19432@atomide.com> <20160202234145.GC19432@atomide.com> <20160203162705.GG19432@atomide.com> Message-ID: <20160203182828.GM19432@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Ulf Hansson [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 :) Regards, Tony