From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757631AbcIPH0D (ORCPT ); Fri, 16 Sep 2016 03:26:03 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:35056 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752045AbcIPHZx (ORCPT ); Fri, 16 Sep 2016 03:25:53 -0400 X-AuditID: cbfec7f5-f79ce6d000004c54-57-57db9e7c6035 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: <37bd85ce-95c9-4614-e1fa-2b189ff90d43@samsung.com> Date: Fri, 16 Sep 2016 09:25:45 +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: <5257325.y9rG1UM74b@vostro.rjw.lan> Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02SeUhUURTGufPevHljTrzGpYPmwsBgGZqCxstCKjJfYNAfxUAINubLMdfm qWlE6qipk5m5oLiL2TIp4rggppgLTmGZS4blkuOSVkjmkBiC1cwz8L/fvec75zvf5ZKYtE3o QEbExLPqGGWUjLDC2wd/D3vcrppSeDX9tKeLjYsEnV7XRNBLLQsCeryzgqBN9wcQvbLsSC+/ 7sboN0NjQjp/a4Sg8xrHCNrQqDi5h+mYeYQYvS6HYKY/dBFMT2WDiGmdyMKZ8plNxDS1TuCM Se/MlGa1Cy+IL1udCGOjIhJZ9RH/K1aqjI+1orhheVJzzxiWiuactUhMAuUDo3UaEc/2MDLb RGiRFSml6hE8qXwuMBeklAnB5Lq7FpGWhsaeIF7zGMFWVR7iD8sICrrakbnBhgqC0Y01wsy2 lAIG9TqhWYRRWwIwVmssBYLyBu2q1sISyh86W3Itbjglh5xX05ZBdlQwzEy+3dHsg83CWdy8 hZjygul1J/M1RvnBl+1MIc8u0NKwipm9gJoXQeHmO5zf2gn0LzE+5RkwpA3gPNvAN0PrTvoD kJPdK+D5AQJN5mGeSxEMr0p4Pg79htEdr71Q0F6C8eMlkH1XyksY+FwxR/B8ChYf1gr599Eh KJwfIfKRS9muNGW7IpTtilCDMB2yZRO46HCW8/XklNFcQky459XYaD3695mGtg2/OlD9oF8f okgks5Y8rfykkAqViVxydB8CEpPZSowVUwqpJEyZfItVx4aoE6JYrg85krhsv6Sr5r1CSoUr 49lIlo1j1f+rAlLskIrqQlXHbKbSg2/EF7W5JWmdkIk7q966VhjoVpF6hyo4Py7bNLr6iJNE a5cgN+3gzLl+RRDyDbgZK2A0ps9c89G2e9+/Wq+U2BZtm2aLXXPshuQ/XkxVkySTElLyrHvJ 7fRFRV5AZWKGRNQxeogIUi1sBPZ6bHhfj0wJLf/DyWU4p1J6u2NqTvkX160OD0gDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsVy+t/xa7oB826HG+ycy2sx9eETNovmxevZ LJ5ufsxkcXnXHDaLz71HGC1ePJe2eH5yL7PFmdOXWC0m/L7AZtG39hKbxfG14Q7cHjvuLmH0 2LSqk83jzrU9bB77565h99hytZ3FY/bdH4we67dcZfH4vEnOY0b7NtYAzig3m4zUxJTUIoXU vOT8lMy8dFul0BA3XQslhbzE3FRbpQhd35AgJYWyxJxSIM/IAA04OAe4Byvp2yW4ZbTcXMhe cE61YuP+S8wNjA/kuhg5OCQETCTW7vfpYuQEMsUkLtxbz9bFyMUhJLCEUWLJ980sIAkhgedA zjxfEFtYwEfi4rcPbCC2iEC4xK8TP1ggGlYxSjyf9psRxGEW+M0k8eX7PHaQKjYBQ4mut11g HbwCdhK7NvcwgdgsAqoSnSfuMIJcISoQI7G+LwGiRFDix+R7LCBhTgEDiTufZEHCzAJmEl9e HmaFsOUlNq95yzyBUWAWko5ZSMpmISlbwMi8ilEktbQ4Nz232FCvODG3uDQvXS85P3cTIzBK tx37uXkH46WNwYcYBTgYlXh4A2bfChdiTSwrrsw9xCjBwawkwms593a4EG9KYmVValF+fFFp TmrxIUZToBcmMkuJJucDE0heSbyhiaG5paGRsYWFuZGRkjhvyYcr4UIC6YklqdmpqQWpRTB9 TBycUg2M+n12FsuS0tyqReSqWKytT8REBOaV/gn98MP2ZcKLrS4LEvnubtrzauVNP4WKxPKE 2b+PeCm98pkvaL9r9kXN5Zsvpq8OOaSTEy95eskf77uVBxg6q+cu/l50wHPXPmGFx8Gx/DM3 7uFPsE29zWg2QfvJt8/WlmdPnd64a9YNhUTd5COlcx1MlViKMxINtZiLihMBQC+tBugCAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20160916072547eucas1p28df910f09cdb8de3b788caa43392235f 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> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland