linux-kernel - Re: [PATCH RFT] regulator: palmas: Don't update tstep register for SMPS3 and SMPS7

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: <5170CEBC.5030200@nvidia.com>
Date:	Fri, 19 Apr 2013 10:27:32 +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: Don't update tstep register for
 SMPS3 and SMPS7

On Friday 19 April 2013 09:11 AM, Axel Lin wrote:
> SMPS3 and SMPS7 do not have tstep_addr setting, so current code actually
> writes 0 to PALMAS_SMPS12_CTRL(0x0) register when set_ramp_delay callback
> is called for SMPS3 and SMPS7.
>
> Signed-off-by: Axel Lin <axel.lin@...ics.com>
> ---
>   drivers/regulator/palmas-regulator.c |    4 ++++
>   1 file changed, 4 insertions(+)
>
> diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
> index f26344e..cfa143a 100644
> --- a/drivers/regulator/palmas-regulator.c
> +++ b/drivers/regulator/palmas-regulator.c
> @@ -438,6 +438,10 @@ static int palmas_smps_set_ramp_delay(struct regulator_dev *rdev,
>   	unsigned int addr = palmas_regs_info[id].tstep_addr;
>   	int ret;
>   
> +	/* SMPS3 and SMPS7 do not have tstep_addr setting */
> +	if (!addr)
> +		return 0;
> +

I avoided to compare the tstep_addr because it can be 0 offset also but 
seeing TPS65913 and TPS80036 (which are palma devices),  seeing that 
valid tstep is always non-zero.
Table are populated for offset and there is base register address for 
group of the configuration like smps12_ctl offset is 0 and base is 0x120 
(TPS65913).

I think similar check need to be there in probe also as part of 
cleanups, in place of checking the reg_id, we can check the tstep.


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