From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757962AbcIPH51 (ORCPT ); Fri, 16 Sep 2016 03:57:27 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:38561 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752183AbcIPH5Q (ORCPT ); Fri, 16 Sep 2016 03:57:16 -0400 X-AuditID: cbfec7f1-f79f46d0000008eb-cf-57dba5d8d1bb Subject: Re: [RFC/RFT][PATCH v3 0/5] Functional dependencies between devices To: "Rafael J. Wysocki" , Linux PM list Cc: Greg Kroah-Hartman , Alan Stern , Linux Kernel Mailing List , Tomeu Vizoso , Mark Brown , Lukas Wunner , Kevin Hilman , Ulf Hansson , "Luis R. Rodriguez" From: Marek Szyprowski Message-id: <51bbee36-380a-6a42-db6b-959d5fec40f8@samsung.com> Date: Fri, 16 Sep 2016 09:57:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-version: 1.0 In-reply-to: <37bd85ce-95c9-4614-e1fa-2b189ff90d43@samsung.com> Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHez07Z2fW4jRNH7QURn5JMs0uBxPTiDiIhB+CQQk69Hgpp7Kp ZH4Rw9ugmoYkXvKueUOYY1lpqZlTTFHzhuZtaUq50jQzdTPnmeC33/s8//f/PP+Xl8REWtyB jIqJZ+Ux0mgxYc3Tdv3rPzdeOSlxrylzonPn5gn6UXkjQS80fbWiP78pJOi1x52IXlp0pBd7 WjH6U+8QTqu2Bwj6ScMQQesaJL5HmeapCsSoa7MI5stoC8G8L6rnM5qRDB5TMLWJmEbNCI9Z UzsxeRlaPFBwx9o7jI2OSmTl531CrCN31et4XLrrg7mtcpSCxsRKRJJAXYTMgUglEuyhHQxM NxJKZE2KqEoERuMKnzusIShdqsIPLrwdtefqVQg2MlotokUEJtVr3GxlQwXA4MYKYWZbSgJd 6lrcLMKobSuYK07dbxCUBygNyn0WUj6gmupAZuZRLrAxYdg3OkkFwdR4n0VzAjafTfPMLKCu wXC6fr+OUV7wzZSGc+wMTfUGzDwMKD0fquuWMW7t06Buw7icN6C8YdvCNvBdp+FzfAqyMtut OH6KIDXNleM8BP0GIcdX4YNu0DLrOORon1vshZCZLuIkDMwUzhIc+8F8dinOPdAMgsGRCr4K OecfipN/KEL+oQglCKtFtmyCQhbBKi64KaQyRUJMhFtorEyN9n5Tr0m32ox+dXt1IIpE4mPC l0UTEhEuTVQkyToQkJjYVlhcMSkRCcOkSQ9ZeWywPCGaVXQgR5Inthe2lAxLRFSENJ69z7Jx rPyga0UKHFLQ5dwfbv7J+naf5dmmW17OZb+d/YQhfWzXiw3fRX2WzXBEZzVKTh1bE/W06b2z E1b9Pakio5E1udsUBuzcvB4e7mb8yZCmI2dUMu2lK5qWj8E1iPYO8NWMum4V5KwHJ77yDqp7 120IvCtw3V1omP8TilwC/trdzrs3veM5XaYR8xSRUo+zmFwh/Q+X0m0QSQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsVy+t/xq7prlt4ON7j3RdRi6sMnbBbNi9ez WTzd/JjJ4vKuOWwWn3uPMFq8eC5t8fzkXmaLM6cvsVpM+H2BzaJv7SU2i+Nrwx24PXbcXcLo sWlVJ5vHnWt72Dz2z13D7rHlajuLx+y7Pxg91m+5yuLxeZOcx4z2bawBnFFuNhmpiSmpRQqp ecn5KZl56bZKoSFuuhZKCnmJuam2ShG6viFBSgpliTmlQJ6RARpwcA5wD1bSt0twy/i/6Qtr QZt2xcNfixkbGK8rdTFycEgImEjsvibexcgJZIpJXLi3nq2LkYtDSGAJo8S2iRsZQRJCAs8Z JQ4uLwSxhQV8JC5++8AGYosIhEv8OvGDBaLhPqPEpZv9rCAOs8BvJokv3+exg1SxCRhKdL3t AuvgFbCTmHD3ENhUFgFViW+33rKCXCEqECOxvi8BokRQ4sfkeywgNqeAvcSVtkdgrcwCZhJf Xh5mhbDlJTavecs8gVFgFpKWWUjKZiEpW8DIvIpRJLW0ODc9t9hQrzgxt7g0L10vOT93EyMw Trcd+7l5B+OljcGHGAU4GJV4eANm3woXYk0sK67MPcQowcGsJMI7f8ntcCHelMTKqtSi/Pii 0pzU4kOMpkA/TGSWEk3OB6aQvJJ4QxNDc0tDI2MLC3MjIyVx3pIPV8KFBNITS1KzU1MLUotg +pg4OKUaGOeIl3Q6aj8qDexILe86m3lixkL2oxrfVbQ+nEq44O7FwhhnF+pwY3rkpzurP3eH t3s1Nqn4x/qVFDxqtNsew/mJ+ULE/8OLX3FxbeFsVp37/xPzT4eHrBeC8peudt37I5pjMsPJ 2wvK+VPmiqouuPJErFciJXCdleFFi2ypU84b59//+f8oixJLcUaioRZzUXEiAKKZboLpAgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20160916075712eucas1p297982134fd5305e730c2ab75e46e8957 X-Msg-Generator: CA X-Sender-IP: 182.198.249.179 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: 20160915220215eucas1p2e246545de6ecaf16fe82a25ed7bc64b2 X-RootMTR: 20160915220215eucas1p2e246545de6ecaf16fe82a25ed7bc64b2 References: <27296716.H9VWo8ShOm@vostro.rjw.lan> <5257325.y9rG1UM74b@vostro.rjw.lan> <37bd85ce-95c9-4614-e1fa-2b189ff90d43@samsung.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Everyone, On 2016-09-16 09:25, Marek Szyprowski wrote: > Hi Rafael, > > On 2016-09-16 00:03, Rafael J. Wysocki wrote: >> Hi Everyone, >> >> On Thursday, September 08, 2016 11:25:44 PM Rafael J. Wysocki wrote: >>> Hi Everyone, >>> >>> This is a refresh of the functional dependencies series that I >>> posted last >>> year and which has picked up by Marek quite recently. For >>> reference, appended >>> is my introductory message sent previously (which may be slightly >>> outdated now). >>> >>> As last time, the first patch rearranges the code around >>> __device_release_driver() >>> a bit to prepare it for the next one (it actually hasn't changed >>> AFAICS). >>> >>> The second patch introduces the actual device links mechanics, but >>> without >>> system suspend/resume and runtime PM support which are added by the >>> subsequent >>> patches. >>> >>> Some bugs found by Marek during his work on these patches should be >>> fixed >>> here. In particular, the endless recursion in device_reorder_to_tail() >>> which simply was broken before. >>> >>> There are two additional patches to address the issue with runtime >>> PM support >>> that occured when runtime PM was disabled for some suppliers due to >>> a PM >>> sleep transition in progress. Those patches simply make runtime PM >>> helpers >>> return 0 in that case which may be controversial, so please let me >>> know if >>> there are concerns about those. >>> >>> The way device_link_add() works is a bit different, as it takes an >>> additional >>> status argument now. That makes it possible to create a link in any >>> state, >>> with extra care of course, and should address the problem pointed to >>> by Lukas >>> during the previous discussion. >>> >>> Also some comments from Tomeu have been addressed. >> An update here. >> >> The first patch hasn't changed, so I'm resending it. >> >> The majority of changes in the other patches are in order to address >> Lukas' >> comments. >> >> First off, I added a DEVICE_LINK_STATELESS flag that will prevent the >> driver >> core from trying to maintain device links having it set. >> >> Also, the DEVICE_LINK_PERSISTENT flag was dropped (as link >> "persistence" is the >> default behavior now) and there's a new one, DEVICE_LINK_AUTOREMOVE, >> that will >> cause the driver core to remove the link on the consumer driver unbind. >> >> Moreover, the code checks attempts to create a link between a parent >> and a child >> device now and actively prevents that from happening. >> >> The changelog of the second patch has been updated as requested by Ulf. >> >> The third patch was updated to fix a bug related to the (previously >> missing) >> clearing of power.direct_complete for supplier devices having >> consumers that >> don't use direct_complete. >> >> The next two (runtime PM) patches turned out to be unnecessary, so >> I've dropped >> them. >> >> The runtime PM patch [4/5] was reorganized somewhat to reduce the >> indentation >> level in there, but the code flow introduced by it is essentially the >> same >> and the last patch was simply rebased on top of the new series. >> >> If this version still works for Marek, I'll probably drop the RFC tag >> from it >> in the next iteration. > > Sadly, this version doesn't work. I get following kernel bug: > > [ 2.357622] BUG: spinlock bad magic on CPU#0, swapper/0/1 > [ 2.362361] lock: 0xeea2e294, .magic: ffffffff, .owner: /0, > .owner_cpu: -1 > [ 2.369389] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 4.8.0-rc6-00019-gd66d0028dd3c-dirty #651 > [ 2.377954] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [ 2.384053] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 2.391766] [] (show_stack) from [] > (dump_stack+0x74/0x94) > [ 2.398970] [] (dump_stack) from [] > (do_raw_spin_lock+0x160/0x1a8) > [ 2.406870] [] (do_raw_spin_lock) from [] > (device_links_no_driver+0x64/0x98) > [ 2.415634] [] (device_links_no_driver) from [] > (driver_probe_device+0xa0/0x2bc) > [ 2.424744] [] (driver_probe_device) from [] > (__driver_attach+0xac/0xb0) > [ 2.433165] [] (__driver_attach) from [] > (bus_for_each_dev+0x54/0x88) > [ 2.441323] [] (bus_for_each_dev) from [] > (bus_add_driver+0xe8/0x1f4) > [ 2.449481] [] (bus_add_driver) from [] > (driver_register+0x78/0xf4) > [ 2.457469] [] (driver_register) from [] > (do_one_initcall+0x3c/0x16c) > [ 2.465632] [] (do_one_initcall) from [] > (kernel_init_freeable+0x120/0x1ec) > [ 2.474313] [] (kernel_init_freeable) from [] > (kernel_init+0x8/0x118) > [ 2.482470] [] (kernel_init) from [] > (ret_from_fork+0x14/0x3c) > > I'm checking what's wrong there. > The issue was caused by missing braces in device_links_no_driver() function. After fixing it the patches works fine, so you can add: Tested-by: Marek Szyprowski Rafael, how and when do you plan to merge them? I would like to know how to process further with my IOMMU patch, which is depends on your patches. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland