From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755352AbcC1U1x (ORCPT ); Mon, 28 Mar 2016 16:27:53 -0400 Received: from lists.s-osg.org ([54.187.51.154]:58752 "EHLO lists.s-osg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751544AbcC1U1v (ORCPT ); Mon, 28 Mar 2016 16:27:51 -0400 Subject: Re: [RFC PATCH] regulator: Try to resolve regulators supplies on registration To: linux-kernel@vger.kernel.org References: <1458777574-3207-1-git-send-email-javier@osg.samsung.com> Cc: stable@vger.kernel.org, Liam Girdwood , Mark Brown , Bjorn Andersson From: Javier Martinez Canillas Message-ID: <56F993BE.1080808@osg.samsung.com> Date: Mon, 28 Mar 2016 16:27:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1458777574-3207-1-git-send-email-javier@osg.samsung.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, [add Bjorn Andersson to cc since I forgot and he authored the mentioned commit] On 03/23/2016 08:59 PM, Javier Martinez Canillas wrote: > Commit 6261b06de565 ("regulator: Defer lookup of supply to regulator_get") > moved the regulator supplies lookup logic from the regulators registration > to the regulators get time. > > Unfortunately, that changed the behavior of the regulator core since now a > parent supply with a child regulator marked as always-on, won't be enabled > unless a client driver attempts to get the child regulator during boot. > > This patch tries to resolve the parent supply for the already registered > regulators each time that a new regulator is registered. So the regulators > that have child regulators marked as always on will be enabled regardless > if a driver gets the child regulator or not. > > That was the behavior before the mentioned commit, since parent supplies > were looked up at regulator registration time instead of during child get. > > Since regulator_resolve_supply() checks for rdev->supply, most of the times > it will be a no-op. Errors aren't checked to keep the possible out of order > dependencies which was the motivation for the mentioned commit. > > Also, the supply being available will be enforced on regulator get anyways > in case the resolve fails on regulators registration. > > Cc: # 4.1+ > Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get") > Suggested-by: Mark Brown > Signed-off-by: Javier Martinez Canillas > > --- > Hello Mark, > > I'm posting this patch as an RFC in case I didn't understood correctly > your latest suggestion mentioned over IRC. > > Best regards, > Javier > > drivers/regulator/core.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c > index 6dd63523bcfe..32ab16c600bd 100644 > --- a/drivers/regulator/core.c > +++ b/drivers/regulator/core.c > @@ -3840,6 +3840,11 @@ static void rdev_init_debugfs(struct regulator_dev *rdev) > &rdev->bypass_count); > } > > +static int regulator_register_resolve_supply(struct device *dev, void *data) > +{ > + return regulator_resolve_supply(dev_to_rdev(dev)); > +} > + > /** > * regulator_register - register regulator > * @regulator_desc: regulator to register > @@ -3986,6 +3991,10 @@ regulator_register(const struct regulator_desc *regulator_desc, > } > > rdev_init_debugfs(rdev); > + > + /* try to resolve regulators supply since a new one was registered */ > + class_for_each_device(®ulator_class, NULL, NULL, > + regulator_register_resolve_supply); > out: > mutex_unlock(®ulator_list_mutex); > kfree(config); > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America