On Wed, Nov 02, 2016 at 08:58:38AM +0100, Marek Szyprowski wrote: > 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?
My trees do not get rebased so you can pull from it directly right now, or if you really need a signed tag, I can make one up, but it will not be until Monday that I can do that. thanks, greg k-h
