All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.com>,
	Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	<linux-kernel@vger.kernel.org>,
	Javier Martinez Canillas <javier@osg.samsung.com>
Subject: Re: [PATCH 1/5] regulator: core: Resolve supply earlier
Date: Mon, 11 Apr 2016 11:59:02 +0100	[thread overview]
Message-ID: <570B8376.6030505@nvidia.com> (raw)
In-Reply-To: <1460038959-21592-1-git-send-email-thierry.reding@gmail.com>

Hi Thierry,

On 07/04/16 15:22, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> Subsequent patches will need access to the parent supply from within the
> set_machine_constraints() function to properly implement bypass mode. If
> the parent supply hasn't been resolved by that time the voltage can't be
> queried.
> 
> Also, by making sure the supply is resolved early most of the changes in
> set_machine_constraints() don't have to be undone if resolution fails.
> 
> Suggested-by: Mark Brown <broonie@kernel.org>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  drivers/regulator/core.c | 27 +++++++++++++++++++++------
>  1 file changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 2786d251b1cc..cc0333a79924 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -3972,18 +3972,27 @@ regulator_register(const struct regulator_desc *regulator_desc,
>  
>  	dev_set_drvdata(&rdev->dev, rdev);
>  
> +	if (init_data && init_data->supply_regulator)
> +		rdev->supply_name = init_data->supply_regulator;
> +	else if (regulator_desc->supply_name)
> +		rdev->supply_name = regulator_desc->supply_name;
> +
> +	/*
> +	 * set_machine_constraints() needs the supply to be resolved in order
> +	 * to support querying the current voltage in bypass mode. Resolve it
> +	 * here to more easily handle deferred probing.
> +	 */
> +	ret = regulator_resolve_supply(rdev);
> +	if (ret < 0)
> +		goto scrub;
> +

Thanks for sending this. However, I think that calling
regulator_resolve_supply() can cause a deadlock, because the
regulator_list_mutex is held at this point and
regulator_resolve_supply() calls regulator_dev_lookup() which may try to
request the mutex again.

So may be we need to move this call after the call to
regulator_of_get_init_data() before we acquire the mutex.

Also, if we add this call, then I am wondering if we still need ...

	class_for_each_device(&regulator_class, NULL, NULL,
			      regulator_register_resolve_supply);

Cheers
Jon

  parent reply	other threads:[~2016-04-11 10:59 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-07 14:22 [PATCH 1/5] regulator: core: Resolve supply earlier Thierry Reding
2016-04-07 14:22 ` [PATCH 2/5] regulator: core: Use parent voltage from the supply when bypassed Thierry Reding
2016-04-12  6:31   ` Applied "regulator: core: Use parent voltage from the supply when bypassed" to the regulator tree Mark Brown
2016-04-07 14:22 ` [PATCH 3/5] regulator: helpers: Ensure bypass register field matches ON value Thierry Reding
2016-04-22 10:49   ` Applied "regulator: helpers: Ensure bypass register field matches ON value" to the regulator tree Mark Brown
2016-04-07 14:22 ` [PATCH 4/5] regulator: as3722: Add bypass support for LDO6 Thierry Reding
2016-04-11 16:15   ` Applied "regulator: as3722: Add bypass support for LDO6" to the regulator tree Mark Brown
2016-04-07 14:22 ` [PATCH 5/5] regulator: as3722: Constify regulator ops Thierry Reding
2016-04-11 16:15   ` Applied "regulator: as3722: Constify regulator ops" to the regulator tree Mark Brown
2016-04-11 10:59 ` Jon Hunter [this message]
2016-04-11 11:46   ` [PATCH 1/5] regulator: core: Resolve supply earlier Thierry Reding
2016-04-11 12:19     ` Jon Hunter
2016-04-11 12:49       ` Mark Brown
2016-04-11 14:03       ` Javier Martinez Canillas
2016-04-11 12:58     ` Mark Brown
2016-04-11 13:09       ` Thierry Reding
2016-04-11 13:45         ` Javier Martinez Canillas
2016-04-11 13:57           ` Mark Brown
2016-04-11 14:07             ` Thierry Reding
2016-04-11 14:32               ` Mark Brown
2016-04-11 14:49                 ` Thierry Reding
2016-04-11 15:50                   ` Mark Brown
2016-04-11 13:56         ` Mark Brown
2016-04-11 14:03 ` Mark Brown
2016-04-11 14:11   ` Thierry Reding
2016-04-11 14:16     ` Mark Brown
2016-04-19 10:16       ` Jon Hunter
2016-04-19 11:03         ` Thierry Reding
2016-04-19 15:40         ` Mark Brown
2016-04-19 16:09           ` Jon Hunter
2016-04-20 15:21             ` Mark Brown
2016-04-21 15:34               ` Jon Hunter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=570B8376.6030505@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=broonie@kernel.org \
    --cc=javier@osg.samsung.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.