From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1 Date: Wed, 3 Feb 2016 10:28:28 -0800 Message-ID: <20160203182828.GM19432@atomide.com> References: <20160202030533.GT19432@atomide.com> <20160202163536.GU19432@atomide.com> <20160202234145.GC19432@atomide.com> <20160203162705.GG19432@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-pm-owner@vger.kernel.org To: Ulf Hansson Cc: Alan Stern , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Kevin Hilman , "linux-pm@vger.kernel.org" , Linux OMAP Mailing List , "linux-arm-kernel@lists.infradead.org" List-Id: linux-omap@vger.kernel.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