Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752101AbdLUKI1 (ORCPT ); Thu, 21 Dec 2017 05:08:27 -0500 Received: from mailout1.w1.samsung.com ([210.118.77.11]:37200 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750884AbdLUKIY (ORCPT ); Thu, 21 Dec 2017 05:08:24 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20171221100821euoutp01e5562e12fbf6f39520a6f22f887caf5e~CR1-avYcF1141311413euoutp01l X-AuditID: cbfec7f2-f793b6d000003243-b8-5a3b8814a637 Subject: Re: [PATCH v3 3/4] regulator: core: Parse coupled regulators properties To: Mark Brown Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Liam Girdwood , Rob Herring , Mark Rutland , Marek Szyprowski , Bartlomiej Zolnierkiewicz From: Maciej Purski Message-id: <4866dd1c-e9bb-24e4-9b4a-294d01edde78@samsung.com> Date: Thu, 21 Dec 2017 11:08:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-version: 1.0 In-reply-to: <20171212113511.GF16323@sirena.org.uk> Content-type: text/plain; charset="windows-1252"; format="flowed" Content-language: en-US Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsWy7djP87oiHdZRBu0NhhYbZ6xntZj68Amb xfwj51gtvl3pYLK4vGsOm8XaI3fZLZZev8hk0br3CLsDh8eaeWsYPXbOusvusWlVJ5tH35ZV jB6fN8kFsEZx2aSk5mSWpRbp2yVwZexrPchYcJKzom3xXbYGxqvsXYycHBICJhJnGx4xQ9hi EhfurWfrYuTiEBJYyiixd8l7FgjnM6PE4jMvGWE6ts8/xwqRWMYo0fTwCxOE84xR4szHU2Bz hQWCJBZMf8UGYosIKEtc/b4XbBSzwEQmiQt/FgN1cHCwCWhJrGmPB6nhFbCTWLb9OyuIzSKg KrGwZRbYNlGBCInjh5czQtQISvyYfI8FxOYUMJbY+fA02HxmAUeJB4t2skLY4hLNrTdZIGx5 ic1r3jKD7JUQuM8mcXbRTqinXSQ+3t/MBmELS7w6vgUqLiPR2XGQCcKulrj4dRdUTY1E4+0N UDXWEp8nbWGGWMAnMWnbdGaQXyQEeCU62oQgSjwkDp9eDg0tR4nfh74yQwLoD6PEngubmCYw ys9C8s8sJD/MQvLDLCQ/LGBkWcUoklpanJueWmysV5yYW1yal66XnJ+7iRGYdE7/O/5pB+PX E1aHGAU4GJV4eBuSraKEWBPLiitzDzFKcDArifBWf7aMEuJNSaysSi3Kjy8qzUktPsQozcGi JM5rG9UWKSSQnliSmp2aWpBaBJNl4uCUamAU/lhvO/HTyz8/OjunBIlcenJcUVDG4v1xrsec S409znxaHG2fc+7+Dlaz9iTJjNxju/oErp7pU1utVFutzf7q7sz+f/2Wb/7vF9t9OGv9pr2u Tg7//DMntXtVx/md6lhefWtu08+rK6Llpf8zVLBVcTXbvJxTdkTF/H3BXZfJnTnSO8QlZ25S YinOSDTUYi4qTgQAJYCGujYDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsVy+t/xy7oiHdZRBivWillsnLGe1WLqwyds FvOPnGO1+Halg8ni8q45bBZrj9xlt1h6/SKTReveI+wOHB5r5q1h9Ng56y67x6ZVnWwefVtW MXp83iQXwBrFZZOSmpNZllqkb5fAlbGv9SBjwUnOirbFd9kaGK+ydzFyckgImEhsn3+OFcIW k7hwbz1bFyMXh5DAEkaJa2veMkE4zxglJpxezwJSJSwQIPHyxROwbhEBZYmr3/eygBQxC0xm kvj2sx2sSEjgD6PElRMyXYwcHGwCWhJr2uNBwrwCdhLLtn8H28YioCqxsGUWI4gtKhAh8bz5 PStEjaDEj8n3wMZwChhL7Hx4mg3EZhawlVjwfh0LhC0u0dx6E8qWl9i85i3zBEbBWUjaZyFp mYWkZRaSlgWMLKsYRVJLi3PTc4sN9YoTc4tL89L1kvNzNzEC42PbsZ+bdzBe2hh8iFGAg1GJ h/dGqlWUEGtiWXFl7iFGCQ5mJRHe6s+WUUK8KYmVValF+fFFpTmpxYcYpTlYlMR5e/esjhQS SE8sSc1OTS1ILYLJMnFwSjUwVn39ZmcdW1uarLZFTmh9r/q5P2d2dLbcO926f6Ft7EWp6fxL TPN5oxSMvKRORZQcPHrl3X6N5zv0d75+L1DAFZv5qfmb9sXru9Y89BFabV2z7iz/irq8mTy7 v53251F692mn3cVrZb6hfWsX5HT/VBbefeDXpXO+el9bRG03My4PkFl6c8erpUosxRmJhlrM RcWJAKlQQwWLAgAA X-CMS-MailID: 20171221100820eucas1p2f4ae577898e88f3f869a2aa917267344 X-Msg-Generator: CA CMS-TYPE: 201P X-CMS-RootMailID: 20171207094753eucas1p27b835787f92a1da8c46b9a2692376288 X-RootMTR: 20171207094753eucas1p27b835787f92a1da8c46b9a2692376288 References: <1512639975-22241-1-git-send-email-m.purski@samsung.com> <1512639975-22241-4-git-send-email-m.purski@samsung.com> <20171212113511.GF16323@sirena.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1200 Lines: 29 On 12/12/2017 12:35 PM, Mark Brown wrote: > On Thu, Dec 07, 2017 at 10:46:14AM +0100, Maciej Purski wrote: >> (...) >> + mutex_lock(®ulator_list_mutex); >> + regulator_resolve_coupling(rdev); >> + mutex_unlock(®ulator_list_mutex); >> + > > I'd really expect us to be failing to probe if we run into an error. > Otherwise we could end up doing bad things to the hardware at runtime > later on, or confusing ourselves and crashing with partially set up > datastructures. We cannot fail to probe if some of the regulators are not registered successfully, as depending on the probing sequence, there will be some regulators, which won't be available when registering others. We can fail when resolving coupling if we encounter other errors such as max_spread not provided or disability to set voltage. Maybe that is what you meant. > It's also not 100% clear to me how we handle the case > where only some of the coupled regulators have probed. > I have two ideas how to handle it. We can prohibit setting the voltage and always fail on attempt to set voltage of a coupled regulator. Or we can just ignore it and set voltage of the regulator without checking the unregistered ones.