[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <6543936.FbWAdBN1tG@kreacher>
Date: Wed, 21 Oct 2020 21:10:08 +0200
From: "Rafael J. Wysocki" <rjw@...ysocki.net>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Linux PM <linux-pm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Lukas Wunner <lukas@...ner.de>,
Saravana Kannan <saravanak@...gle.com>,
Xiang Chen <chenxiang66@...ilicon.com>
Subject: [PATCH 0/3] PM: runtime: Fixes related to device links management
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.
Thanks!
Powered by blists - more mailing lists