linux-kernel - Re: [PATCH RFT] regulator: palmas: Fix off-by-one for ramp

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: <5174FFC3.70603@nvidia.com>
Date:	Mon, 22 Apr 2013 14:45:47 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Axel Lin <axel.lin@...ics.com>
CC:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Graeme Gregory <gg@...mlogic.co.uk>,
	Liam Girdwood <lgirdwood@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFT] regulator: palmas: Fix off-by-one for ramp_delay
 and register value mapping

On Sunday 21 April 2013 10:28 PM, Axel Lin wrote:
> In probe(), we have below code to set ramp_delay:
> e.g. When reg is 2, current code set
> pmic->desc[id].ramp_delay = palmas_smps_ramp_delay[reg & 0x3];
>                            = 5000
> which means ramp_delay = 5000 is mapping to reg value = 2;
>
> However, in palmas_smps_set_ramp_delay()
>          ramp_delay = 5000 is mapping to reg value = 1.
>
> This patch fixes the off-by-one value range checking for ramp_delay in
> palmas_smps_set_ramp_delay().
>
> Signed-off-by: Axel Lin <axel.lin@...ics.com>
> ---
> Hi Laxman,
> I don't have the datasheet, so please check if this fix is correct.
>
> Thanks,
> Axel
>   drivers/regulator/palmas-regulator.c |    4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
> index 8fed60c..e3e8373 100644
> --- a/drivers/regulator/palmas-regulator.c
> +++ b/drivers/regulator/palmas-regulator.c
> @@ -447,9 +447,9 @@ static int palmas_smps_set_ramp_delay(struct regulator_dev *rdev,
>   
>   	if (ramp_delay <= 0)
>   		reg = 0;
> -	else if (ramp_delay < 2500)
> +	else if (ramp_delay <= 2500)From 6f6875db93eeff52d39623dd68522e1875cf5ef1 Mon Sep 17 00:00:00 2001
> From: Axel Lin <axel.lin@...ics.com>
> Date: Mon, 22 Apr 2013 00:50:55 +0800
> Subject: [PATCH RFT] regulator: palmas: Fix off-by-one for ramp_delay and register value mapping
>
> In probe(), we have below code to set ramp_delay:
> e.g. When reg is 2, current code set
> pmic->desc[id].ramp_delay = palmas_smps_ramp_delay[reg & 0x3];
>                            = 5000
> which means ramp_delay = 5000 is mapping to reg value = 2;
>
> However, in palmas_smps_set_ramp_delay()
>          ramp_delay = 5000 is mapping to reg value = 1.
>
> This patch fixes the off-by-one value range checking for ramp_delay in
> palmas_smps_set_ramp_delay().
>
> Signed-off-by: Axel Lin <axel.lin@...ics.com>
> ---
> Hi Laxman,
> I don't have the datasheet, so please check if this fix is correct.
>

Datasheet says:
Time Step (TSTEP) selection, when changing the
output voltage, the new value is reached through
successive voltage steps (if not bypassed). The
equivalent programmable slew rate of the output
voltage is:
TSTEP[1:0]: 00 Jump (no slope control)
TSTEP[1:0]: 01 10mV/us
TSTEP[1:0]: 10 5mV/us (default)
TSTEP[1:0]: 11 2.5mV/us

--
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/