From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756926AbbCCQQN (ORCPT ); Tue, 3 Mar 2015 11:16:13 -0500 Received: from seldrel01.sonyericsson.com ([212.209.106.2]:4202 "EHLO seldrel01.sonyericsson.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751273AbbCCQQL (ORCPT ); Tue, 3 Mar 2015 11:16:11 -0500 Date: Tue, 3 Mar 2015 08:15:41 -0800 From: Bjorn Andersson To: Mark Brown CC: Chanwoo Choi , Ian Campbell , Krzysztof Kozlowski , Kumar Gala , Lee Jones , Liam Girdwood , Mark Rutland , Pawel Moll , Rob Herring , Stephen Boyd , Andy Gross , Srinivas Kandagatla , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-msm@vger.kernel.org" Subject: Re: [PATCH 2/4] regulator: core: Expose init_data to of_parse_cb Message-ID: <20150303161541.GE26334@sonymobile.com> References: <1425356740-26285-1-git-send-email-bjorn.andersson@sonymobile.com> <1425356740-26285-3-git-send-email-bjorn.andersson@sonymobile.com> <20150303125033.GO21293@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20150303125033.GO21293@sirena.org.uk> User-Agent: Mutt/1.5.22 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 03 Mar 04:50 PST 2015, Mark Brown wrote: > On Mon, Mar 02, 2015 at 08:25:38PM -0800, Bjorn Andersson wrote: > > > Expose the newly created init_data to the driver's parse callback so > > that it can futher enhance it with e.g. constraints of the regulator. > > Why would the driver need to do that? I guess I'll see later on in the > series but the changelog should make that clear. Drivers aren't > supposed to ever need to look at their init data, modifying the init > data from what the machine provied is usually a red flag. > I think what you're getting at is that the init_data should come from a board file or device tree. With the reworkings done in patch 4 this makes more sense than it did before (e.g. I no longer call of_get_regulator_init_data()). However, by calling register_regulator() with dev->of_node being non-NULL and desc->of_match being something that will match a DT entry all init_data is now coming from device tree, through: regulator_register() regulator_of_get_init_data() of_get_regulator_init_data() of_get_regulation_constraints() As this matches a regulator, there is no way for the driver (or anyone else to affect the init_data). The problem at hand is that there is nothing in this code path telling the core that we can do DRMS - something we can figure out in the driver by basically looking at the ops for the registering regulator. > > This is needed because calling regulator_register() with a of_node and > > of_match will overwrite the passed config->init_data. An alternative way > > would be to merge the parsed init_data with the driver provided one. > > Put any explanation as to why the feature is needed in the changelog. Point taken. Let me know if you think I'm on a sane path with the above reasoning and I can resend the patch with a better description of the problem at hand. Regards, Bjorn