From mboxrd@z Thu Jan 1 00:00:00 1970 From: Javier Martinez Canillas Subject: Re: [PATCH v4 10/14] regulator: of: Add support for parsing initial and suspend modes Date: Tue, 04 Nov 2014 12:07:02 +0100 Message-ID: <5458B356.5000206@collabora.co.uk> References: <1415025649-8119-1-git-send-email-javier.martinez@collabora.co.uk> <1415025649-8119-11-git-send-email-javier.martinez@collabora.co.uk> <1415097677.7941.8.camel@AMDC1943> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1415097677.7941.8.camel@AMDC1943> Sender: linux-samsung-soc-owner@vger.kernel.org To: Krzysztof Kozlowski Cc: Mark Brown , Kukjin Kim , Chanwoo Choi , Olof Johansson , Chris Zhong , Abhilash Kesavan , linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org List-Id: devicetree@vger.kernel.org Hello Krzysztof, On 11/04/2014 11:41 AM, Krzysztof Kozlowski wrote: >> + if (!of_property_read_u32(np, "regulator-initial-mode", &pval)) { >> + if (desc && desc->map_modes) >> + constraints->initial_mode = desc->map_modes(pval); >> + else >> + pr_warn("%s: failed to parse regulator-initial-mode\n", >> + np->name); >> + } >> + > > Here's a hidden assumption that if driver does not provide map_modes > then any "regulator-initial-mode" property is not valid. Shouldn't this > be mentioned somewhere? Maybe in description of map_modes callback? > Well it can't be valid if the regulator core does not know how to map the value in the property to one of the standard modes. The binding explains that each PMIC has to define its hardware modes, I can also add a note in the .map_modes. I guess no one will say no to more documentation :-) Best regards, Javier