From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753301AbcKHGgy (ORCPT ); Tue, 8 Nov 2016 01:36:54 -0500 Received: from mailout3.w1.samsung.com ([210.118.77.13]:44369 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752288AbcKHGgv (ORCPT ); Tue, 8 Nov 2016 01:36:51 -0500 X-AuditID: cbfec7ef-f79e76d000005b57-53-58217280b4a5 Subject: Re: [PATCH v6 0/5] Functional dependencies between devices To: "Luis R. Rodriguez" Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Linux PM list , Alan Stern , Linux Kernel Mailing List , Tomeu Vizoso , Mark Brown , Lukas Wunner , Kevin Hilman , Ulf Hansson , Joerg Roedel , Jiri Kosina , Jiri Slaby , Andrzej Hajda , Laurent Pinchart , Lars-Peter Clausen , Grant Likely From: Marek Szyprowski Message-id: <23e4a2bd-41d4-5e14-9539-2acf326dd534@samsung.com> Date: Tue, 08 Nov 2016 07:36:45 +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: <20161107211526.GG1764@wotan.suse.de> Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHOXsvexVXb3PlodltEUmWtSg4VmoXqVMEBQVJBLXszVWbq70a mhCW1y1qpkbelTQ/mOa8RyrWMs1aarNJpEYXzUtqln4wBMvtneG33/Oc33PO/4HDENIpajlz ITyC04erNAranaxt+dOxKVa/JmRLTqon+vi4nUL3vvTTaMRaQaO4wnIa1ecUksiQbRajdPOE CA1UfROhorR8ChnuFolR19McGk3ebgZoaFCOPqQMAGR9Y6NQykwnje6U2WjUWnZitxT3P88T 4Sd9RQBnJ2dSuLLEQOPe7gYaN+WWinHRqIXC1fYkEmf3TQN8p7oE4D/DG3F5tZ3E1oJmMZ6s XIkzkmqpo4tPuu86x2kuXOX0mwPPuKsTLYrLf72jeh/lglhQ62UEbgxkt8G6iUYg8DLY+amc NgJ3RsoWA2hPzqCEYhLAwZpxan5i8NcL8r/1+HW/qxgEMLsu3Wl5svugsW+KdLCM9YVxQ10i h0SwdRSc6rE5JZpVQuOYkXawhA2EPcNvnUFIdh0saEh1Di9lT8Ge9G5CcJbA6bRPzr4buxV+ 7isUOZhgd8DvswmUwKtgVekYIURtYGD6zCEjYOZ4Bax85moHw9ThBNfOnnCktVossDfsSrtF CmwC8GaCr8AZALaPSQTeCV+0vnM9tQim1t4nhOslMDlRKiCGD5oPCvYemNkihJGyZSKYHH8+ BazKWrBL1oL8WQvyFwCiBMi4SF4bxvFKP16l5SPDw/xCddpKMPcX38y2/nwCBuKOWwDLAIWH ZMi0OkRKqa7y0VoLgAyhkEkeXlkTIpWcU0Vf4/S60/pIDcdbgJwhFV6SxoL3J6RsmCqCu8Rx lzn9/KmIcVseC9Q71t/QKr4E2Mw/7x0IjYk3dRiO7B3x2eJ/rKa7KdH7vuS0bdYrvtAcczbn +vaaoCVdmVlJN3BssaleE/X1ty6o9Jh67av9oy/NZIOsLcU/3xshZe5Xw7g1N1xW2tlGebRV /Cg+3L822I6DL/JyZR2Td9KuS6vwscuNn0ObAhQkr1YpNxB6XvUP3Hpy6YcDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsVy+t/xK7qJRYoRBkun81rcWneO1WLqwyds Fq/ObGSzaF68ns1i95zFLBadszewW0zZ8IHJ4unmx0wWSybPZ7XonLiE3eLyrjlsFp97jzBa vHgubXFjwlNGizOnL7FaTPh9gc2ib+0lNovja8MdhDyeHJzH5LHj7hJGj9kdM1k9Nq3qZPO4 c20Pm8f+uWvYPZa8OcTqseVqO4vH7Ls/GD36tqxi9Pj5Usdj/ZarLB5nFhxh9/i8Sc5jRvs2 1gD+KDebjNTElNQihdS85PyUzLx0W6XQEDddCyWFvMTcVFulCF3fkCAlhbLEnFIgz8gADTg4 B7gHK+nbJbhltB1SKvgvU3Fn9VzGBsZt4l2MnBwSAiYSzz8eZoGwxSQu3FvP1sXIxSEksIRR ovX5bnYI5zmjxO9bv5lBqoQFnCW67n4B6xAR0JZofnGZCaJoLZPEsZMfWUAcZoHdrBLTV/xn BKliEzCU6HrbxQZi8wrYSdx+eRYsziKgKrFgzySwSaICMRLXnz2CqhGU+DH5HlicU8BI4sHd xUwgNrOAmcSXl4dZIWx5ic1r3jJPYBSYhaRlFpKyWUjKFjAyr2IUSS0tzk3PLTbSK07MLS7N S9dLzs/dxAhMFduO/dyyg7HrXfAhRgEORiUe3hf9ChFCrIllxZW5hxglOJiVRHiXFipGCPGm JFZWpRblxxeV5qQWH2I0BXpiIrOUaHI+MI3llcQbmhiaWxoaGVtYmBsZKYnzTv1wJVxIID2x JDU7NbUgtQimj4mDU6qB0Wryqes2et1126f0v9q2pKD0Ud7Go7v/sKg8z2TOfhCQvDTs58pz PgeviLdk9/HZ72R9n6vo9CihwiT69A1nxoucqqmrRW9tVH8c7mUYGP4s5g1jVOv3tOW+j/I3 bvcNCVgtns273HK3VFDvMadnnK3v/k0r0KmpMS90OKtQtL3f4ejzWeVhSizFGYmGWsxFxYkA ieDwxCsDAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20161108063646eucas1p2b7d44860dd408c22d511fd1416fca3c8 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> <20161107211526.GG1764@wotan.suse.de> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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