Messages in this thread | | | Subject | Re: [PATCH v6 0/5] Functional dependencies between devices | From | Marek Szyprowski <> | Date | Wed, 02 Nov 2016 08:58:38 +0100 |
| |
Hi Greg,
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?
Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
| |