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