Re: [PATCH RFT] regulator: palmas: Don't update tstep register forSMPS3 and SMPS7

[Laxman Dewangan]

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@xxxxxxxxxx>
> ---
>   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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/