linux-kernel - Re: [RFC PATCH] regulator: Try to resolve regulators supplies on registration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <56F993BE.1080808@osg.samsung.com>
Date:	Mon, 28 Mar 2016 16:27:42 -0400
From:	Javier Martinez Canillas <javier@....samsung.com>
To:	linux-kernel@...r.kernel.org
Cc:	stable@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,
	Bjorn Andersson <bjorn.andersson@...aro.org>
Subject: Re: [RFC PATCH] regulator: Try to resolve regulators supplies on
 registration

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: <stable@...r.kernel.org> # 4.1+
> Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")
> Suggested-by: Mark Brown <broonie@...nel.org>
> Signed-off-by: Javier Martinez Canillas <javier@....samsung.com>
> 
> ---
> 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(&regulator_class, NULL, NULL,
> +			      regulator_register_resolve_supply);
>  out:
>  	mutex_unlock(&regulator_list_mutex);
>  	kfree(config);
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America