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-next>] [day] [month] [year] [list]
Message-ID: <84B43340-7E4D-474B-9217-56E809FF16A9@marvell.com>
Date:	Fri, 15 Jun 2012 11:29:51 -0700
From:	Philip Rakity <prakity@...vell.com>
To:	Pankaj Jangra <jangra.pankaj9@...il.com>
CC:	Philip Rakity <philipspatches@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"broonie@...nsource.wolfsonmicro.com" 
	<broonie@...nsource.wolfsonmicro.com>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>
Subject: Re: [PATCH 1/2] regulator: core.c Pass voltage to notifier when
 setting voltage


On Jun 15, 2012, at 10:58 AM, Pankaj Jangra wrote:

> Hi Philip,
> 
> Just a cosmetic comments.
> 
> On Fri, Jun 15, 2012 at 3:36 AM, Philip Rakity <philipspatches@...il.com> wrote:
> V2
> --
> 
> Incorporate performance suggestions made by Mark Brown
> Use linux-next as base code rather than mmc-next
> 
> The voltage being set should be passed to the handler requesting
> the callback.  Currently this is not done.

thanks -- my typo when redoing the patch -- V3 has this fixed.

> 
> The callback cannot call regulator_get_voltage() to get the
> information since the mutex is held by the regulator and
> deadlock occurs.
> 
> Without this change the receiver of the notify cannot now what
>  
> You mean to say "cannot know what" ?   
> 
> action to take.  This is used, for example, to set PAD voltages
> when doing SD vccq voltage changes.


if you call in that receives the notify does not know the new voltage
then in our case we do not know if we should switch the pad from
3.3v to 1.8v for example.  vccq signaling in SD is normally 3.3V
but in UHS mode it is lowered to 1.8V

> 
> Signed-off-by: Philip Rakity <prakity@...vell.com>
> ---
>  drivers/regulator/core.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 63507a5..5b04916 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -2153,7 +2153,7 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
>        if (rdev->desc->ops->list_voltage)
>                best_val = rdev->desc->ops->list_voltage(rdev, selector);
>        else
> -               best_val = -1;
> +               best_val = _regulator_get_voltage(rdev);
> 
>        /* Call set_voltage_time_sel if successfully obtained old_selector */
>        if (_regulator_is_enabled(rdev) && ret == 0 && old_selector >= 0 &&
> @@ -2176,9 +2176,9 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
>                udelay(delay);
>        }
> 
> -       if (ret == 0)
> +       if (ret == 0 && best_val >= 0)
>                _notifier_call_chain(rdev, REGULATOR_EVENT_VOLTAGE_CHANGE,
> -                                    NULL);
> +                                    (void *)best_val);
> 
> 
> I am also curious to know if you pass the  voltage here to notifier call how does it make any difference, since in 
> blocking_notifier_call_chain() again passes the NULL. So does your patch should  modify the arguments to this function also?
> Please let me know if i am missing something in understanding.
> 
> Regards,
> Pankaj Jangra
> 
>        trace_regulator_set_voltage_complete(rdev_get_name(rdev), best_val);
> 
> --
> 1.7.0.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ