From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752899AbcKBH6r (ORCPT ); Wed, 2 Nov 2016 03:58:47 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:18249 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750899AbcKBH6p (ORCPT ); Wed, 2 Nov 2016 03:58:45 -0400 X-AuditID: cbfec7f4-f791c6d000006eac-3c-58199cb03466 Subject: Re: [PATCH v6 0/5] Functional dependencies between devices To: Greg Kroah-Hartman , "Rafael J. Wysocki" Cc: Linux PM list , Alan Stern , Linux Kernel Mailing List , Tomeu Vizoso , Mark Brown , Lukas Wunner , Kevin Hilman , Ulf Hansson , "Luis R. Rodriguez" , Joerg Roedel From: Marek Szyprowski Message-id: Date: Wed, 02 Nov 2016 08:58:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-version: 1.0 In-reply-to: <20161031174703.GA25633@kroah.com> Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyyUcRzH973nxz2uu3rcKR9U1m2t0SIb2zMVmpbHVkt/MWvp5PGjHLpD sdlUpDsj86P83pVIRoQktIRRUzo/y4Vq+ZW5ViNjlXL3sPnv9fl+3p/P+/PevhQmbSdsqYio WE4VpYiUkyK8qXvl3YG6YpuAg41zbkzel0mSuV5WSzKaojohM9XwVcAMthSTzEJGF2JmZ+yY mdfPMeZN7wDBZP3Wk0xmzQDJ9NT4e4nZyZelArZ5/D5i66s0JDs20kayL0qqhWzjcBrOFo0v I7a2cRhnF+p3s/lpTYSfKFB0OISLjIjnVM4e50ThmvdOMbPWV/qrRolklCPTIgsKaFdI7c0R 8LwD9BO1pBaJKCldjqCu9x/OFwsIVit1go2JT2Mz640KBLXlDwm+mEGgzftAmlQy2hu044u4 ia3os9A0eheZRBidi8HfpQHzKpJ2Aa1Rax6Q0B6QmT1kHsDpvVBizCJMvJ0+Ax9zRzBeYwnL ORNmjQXtDBX9j8zvGO0O06upBM/20FBtxExmQBuFkJI+u2ZGrRW7oL4d4yMcg2cGA8mzDOZ6 GoU874TBnHSc51sIrqXu5zkfQZ9RwvMh6OzpX/faCtlNdzB+vQRu3pDyyMK9Ll9efRQKuvlr pLQeQWFzC5aF7As3pSnclKBwUwIdwqqQFRenVoZxalcntUKpjosKczofraxHa/+qd7VnsRmV dbt3IJpCcrFktgICpIQiXp2g7EBAYXIryekCmwCpJESRkMipooNUcZGcugPZUbjcWtKmG/KX 0mGKWO4ix8Vwqo2ugLKwTUbiLS6Gsl/Bia3LK0vRnZ/1x4PDuv94TNvJLnNuPkUJ3iFDrU+/ eSV7nso/UeqwTUn7OozDyRhDv/ht5WDu49HvfrZyTZunX+y8NBR/kr5Po+/bkxH6U/Yg3vPS 7ZqpC4E6n6nihiPzY8Wvgmz8ryal/JgwdBHCJGvHilhLHW7ZIMfV4QoXR0ylVvwHC+PcBVMD AAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsVy+t/xq7oT5khGGKyZZWEx9eETNovmxevZ LDpnb2C3eLr5MZPF5V1z2Cw+9x5htHjxXNri+cm9zBZnTl9itZjw+wKbRd/aS2wWx9eGO/B4 PDk4j8ljx90ljB6bVnWyedy5tofNY//cNeweW662s3jMvvuD0WP9lqssHp83yXnMaN/GGsAV 5WaTkZqYklqkkJqXnJ+SmZduqxQa4qZroaSQl5ibaqsUoesbEqSkUJaYUwrkGRmgAQfnAPdg JX27BLeMzut6BS/EKy6uusnawDhZuIuRk0NCwETi/p3nLBC2mMSFe+vZuhi5OIQEljBK3P2y jAnCec4oMfX6F1aQKmEBZ4muu1/AOkQE4iRmLf/MDFF0gVFiw6f57CAOs8A0Zon2a9PYQKrY BAwlut52gdm8AnYSfZOugHWzCKhKzH07AWyqqECMxPVnj6BqBCV+TL4HVsMpoC+x7OI6ZhCb WcBM4svLw6wQtrzE5jVvmScwCsxC0jILSdksJGULGJlXMYqklhbnpucWG+kVJ+YWl+al6yXn 525iBMbvtmM/t+xg7HoXfIhRgINRiYd3whKJCCHWxLLiytxDjBIczEoivIEzJSOEeFMSK6tS i/Lji0pzUosPMZoCPTGRWUo0OR+YWvJK4g1NDM0tDY2MLSzMjYyUxHmnfrgSLiSQnliSmp2a WpBaBNPHxMEp1cBYeMt3wf0f+/qcGH7Mnh/84ubxxaLnN1jtOusyX1NKpfx00abQXyFsj+67 TYuufnqD518p5wruMw0sLx6ZeT72Lsr1+H3mreuG3WuWegfk7PuzzvNf1zumn8tiJDlF9a9o bqntFr39UT994pl9tc88RNnsFDiehUV6Lih3kZgVHLBjxXLmppZNSizFGYmGWsxFxYkA4iq+ WfUCAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20161102075840eucas1p1be09dbcabb0923418920fea99281eb22 X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRs=?= =?UTF-8?B?7IK87ISx7KCE7J6QG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Global-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRtT?= =?UTF-8?B?YW1zdW5nIEVsZWN0cm9uaWNzG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTI=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20161031174700eucas1p1cf129b22ebd3dc689172e837ac01647e X-RootMTR: 20161031174700eucas1p1cf129b22ebd3dc689172e837ac01647e References: <27296716.H9VWo8ShOm@vostro.rjw.lan> <11468990.WB1J8sxXpS@vostro.rjw.lan> <20161031174703.GA25633@kroah.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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