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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx> # 4.1+
> Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")
> Suggested-by: Mark Brown <broonie@xxxxxxxxxx>
> Signed-off-by: Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx>
> 
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]