Re: [PATCH v6 0/5] Functional dependencies between devices

From: Marek Szyprowski
Date: Tue Nov 08 2016 - 01:36:57 EST


Hi Luis,


On 2016-11-07 22:15, Luis R. Rodriguez wrote:
On Wed, Nov 02, 2016 at 08:58:38AM +0100, Marek Szyprowski wrote:
On 2016-10-31 18:47, Greg Kroah-Hartman wrote:
On Sun, Oct 30, 2016 at 05:22:13PM +0100, Rafael J. Wysocki wrote:
Let me quote from the previous intro messages for this series first:

Time for another update. :-)

Fewer changes this time, mostly to address issues found by Lukas and
Marek.

The most significant one is to make device_link_add() cope with the case
when
the consumer device has not been registered yet when it is called. The
supplier device still is required to be registered and the function will
return NULL if that is not the case.

Another significant change is in patch [4/5] that now makes the core apply
pm_runtime_get_sync()/pm_runtime_put() to supplier devices around the
probing of a consumer one (in analogy with the parent).
One more update after some conversations during LinuxCon Europe.

The main point was to make it possible for device_link_add() to figure out
the initial state of the link instead of expecting the caller to provide it
which might not be reliable enough in general.

In this version device_link_add() takes three arguments, the supplier and
consumer pointers and flags and it sets the correct initial state of the
link automatically (unless invoked with the "stateless" flag, of course).
The cost is one additional field in struct device (I moved all of the
links-related fields in struct device to a separate sub-structure while at
it) to track the "driver presence status" of the device (to be used by
device_link_add()).

In addition to that, the links list walks in the core.c and dd.c code are
under the device links mutex now, so the iternal link spinlock is not needed
any more and I have renamed symbols to distinguish between flags, link
states and device "driver presence statuses".
The most significant change in this revision with respect to the previous one is
related to the fact that SRCU is not available on some architectures, so the
code falls back to using an RW semaphore for synchronization if SRCU is not
there. Fortunately, the code changes needed for that turned out to be quite
straightforward and confined to the second patch.

Apart from this, the flags are defined using BIT(x) now (instead of open coding
the latter in the flag definitions).

Updated is mostly patch [2/5]. Patches [1,3,5/5] have not changed (except for
trivial rebasing) and patch [4/5] needed to be refreshed on top of the modified
[2/5].

FWIW, I've run the series through 0-day which has not reported any problems
with it.
Great, they are now applied to my tree, thanks again for doing this
work.
Thanks for merging those patches! Could you provide a stable tag with them,
so I can
ask Joerg to merge my Exynos IOMMU PM patches on top of it via IOMMU tree?
You want these patches to be merged into stable?! This is a whole new set of
functionality, the patches in no way describe any *fixes* or critical issues,
why are you saying this is needed? What makes you believe this is a stable
candidate?

I don't want to merge those patches to stale kernel release. By 'stable tag' I just
meant something that can be pulled by Joerg to have a base for my Exynos IOMMU
patches.

Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland