* Ulf Hansson <ulf.hansson@xxxxxxxxxx> [160203 10:38]: > On 3 February 2016 at 19:28, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > * Ulf Hansson <ulf.hansson@xxxxxxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
