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. Kind regards Uffe -- 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
