Hi Greg, On Wed, Oct 21, 2020 at 9:14 PM Rafael J. Wysocki <[email protected]> wrote: > > Hi Greg & all, > > Commit d12544fb2aa9 ("PM: runtime: Remove link state checks in > rpm_get/put_supplier()") merged recently introduced a weakness > in the handling of device links in the runtime PM framework that > may be confusing and even harmful. > > Namely, the checks removed by that commit prevented PM-runtime from > getting or dropping references to the supplier device whose driver > was going away via its links to consumers, which specifically allowed > the pm_runtime_clean_up_links() called from __device_release_driver() > to run without interfering with runtime suspend/resume of consumer > devices (which still might happen even though the drivers had been > unbound from them by that time). > > After the above commit, calling pm_runtime_clean_up_links() from > __device_release_driver() makes a little sense and it may be interfering > destructively with regular PM-runtime suspend/resume control flows, so > it needs to be either fixed or dropped altogether. I prefer the latter, > because among other things this removes an arbitrary difference in the > handling of managed device links with respect to the stateless ones, > so patch [2/3] is doing just that. > > However, in some rare cases pm_runtime_clean_up_links() may help to clean > up leftover PM-runtime references, so if that function goes away, they > need to be cleaned up elsewhere. That's why patch [1/3] modifies > __device_link_del() to drop them upon device link removal (which also > needs to be done for stateless device links and that's why I'm regarding > this patch as a fix). > > Finally, to avoid pointless overhead related to suspending and resuming > the target device for multiple times in a row in __device_release_driver(), > it is better to resume it upfront before checking its links to consumers, > which is done by patch [3/3]. > > While this series touches the driver core, it really is mostly related to > runtime PM, so I can apply it if that's OK.
Any concerns regarding this series? If not, I'd like to queue it up for -rc3, because the current behavior in there is quite confusing (or worse). Cheers!
