Skip to contentSkip to conversation

regulator: Move VCOINCELL to be the last element of mc13892_regulators array

PATCH In review Axel Lin 3 participants 6 messages May 5, 2011 – May 10, 2011 Voltage and current regulator framework

lore
Share & tools
lore

Axel Lin

author
#0 lore raw

PATCH 1/1 regulator: Move VCOINCELL to be the last element of mc13892_regulators array

In include/linux/mfd/mc13892.h, we define MC13892_VCOINCELL as 23.
Thus VCOINCELL should be defined as 23th element in mc13892_regulators array, not the first one. This actually fixes an off-by-one bug while accessing mc13892_regulators array.

For example,
In mc13892_regulator_probe, we use MC13892_VCAM as array index of mc13892_regulators array.

        mc13892_regulators[MC13892_VCAM].desc.ops->set_mode
                = mc13892_vcam_set_mode;

Currently, it access mc13892_regulators[12] ,which is VAUDIO not VCAM.

---
I don't have this hardware handy, just found this bug while reading the code. I appreciate if someone can test it.

Axel

 drivers/regulator/mc13892-regulator.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/regulator/mc13892-regulator.c +1 -1
index 1b8f739..ba909cb 100644
@@ -259,7 +259,6 @@ static struct regulator_ops mc13892_sw_regulator_ops;
 			mc13xxx_regulator_ops)
 
 static struct mc13xxx_regulator mc13892_regulators[] = {
-	MC13892_DEFINE_REGU(VCOINCELL, POWERCTL0, POWERCTL0, mc13892_vcoincell),
 	MC13892_SW_DEFINE(SW1, SWITCHERS0, SWITCHERS0, mc13892_sw1),
 	MC13892_SW_DEFINE(SW2, SWITCHERS1, SWITCHERS1, mc13892_sw),
 	MC13892_SW_DEFINE(SW3, SWITCHERS2, SWITCHERS2, mc13892_sw),
@@ -293,6 +292,7 @@ static struct mc13xxx_regulator mc13892_regulators[] = {
 	MC13892_GPO_DEFINE(GPO4, POWERMISC, mc13892_gpo),
 	MC13892_GPO_DEFINE(PWGT1SPI, POWERMISC, mc13892_pwgtdrv),
 	MC13892_GPO_DEFINE(PWGT2SPI, POWERMISC, mc13892_pwgtdrv),
+	MC13892_DEFINE_REGU(VCOINCELL, POWERCTL0, POWERCTL0, mc13892_vcoincell),
 };
 
 static int mc13892_powermisc_rmw(struct mc13xxx_regulator_priv *priv, u32 mask,
Signature · 1 line
1.7.1
Acked-by on v1 1/1
#1 lore raw
Quoted 3 lines · Axel Lin

In include/linux/mfd/mc13892.h, we define MC13892_VCOINCELL as 23.
Thus VCOINCELL should be defined as 23th element in mc13892_regulators array, not the first one. This actually fixes an off-by-one bug while accessing mc13892_regulators array.

#2 lore raw
In reply to Axel Lin
Quoted 8 lines · Axel Lin

In include/linux/mfd/mc13892.h, we define MC13892_VCOINCELL as 23.
Thus VCOINCELL should be defined as 23th element in mc13892_regulators array, not the first one. This actually fixes an off-by-one bug while accessing mc13892_regulators array.

For example,
In mc13892_regulator_probe, we use MC13892_VCAM as array index of mc13892_regulators array.

        mc13892_regulators[MC13892_VCAM].desc.ops->set_mode
                = mc13892_vcam_set_mode;
Quoted 8 lines

Currently, it access mc13892_regulators[12] ,which is VAUDIO not VCAM.

---
I don't have this hardware handy, just found this bug while reading the code. I appreciate if someone can test it.

Axel

Applied, Btw is this fix also for 2.6.39 ?

Thanks

Liam

author
#3 lore raw

hi Liam,

Quoted 1 line

Applied, Btw is this fix also for 2.6.39 ?

I check this patch again and found this actually is not a bug because MC13xxx_DEFINE explictly defines the order of each entry in the array.

#define MC13xxx_DEFINE(prefix, _name, _reg, _vsel_reg, _voltages, _ops) \
        [prefix ## _name] = {                           \
                .desc = {                                               \
                        .name = #prefix "_" #_name,                     \
                        .n_voltages = ARRAY_SIZE(_voltages),            \
                        .ops = &_ops,                   \
                        .type = REGULATOR_VOLTAGE,                      \
                        .id = prefix ## _name,          \
                        .owner = THIS_MODULE,                           \
                },                                                      \
                .reg = prefix ## _reg,                          \
                .enable_bit = prefix ## _reg ## _ ## _name ## EN,       \
                .vsel_reg = prefix ## _vsel_reg,                        \
                .vsel_shift = prefix ## _vsel_reg ## _ ## _name ## VSEL,\
                .vsel_mask = prefix ## _vsel_reg ## _ ## _name ## VSEL_M,\
                .voltages =  _voltages,                                 \
        }

Regards,
Axel

#4 lore raw
Quoted 7 lines · Axel Lin

hi Liam,

Quoted 1 line

Applied, Btw is this fix also for 2.6.39 ?

I check this patch again and found this actually is not a bug because MC13xxx_DEFINE explictly defines the order of each entry in the array.

:(

I've already pushed this into next, can you send a fix asap.

Thanks

Liam

author
#5 lore raw

2011/5/10 Liam Girdwood <[email protected]>:

Quoted 10 lines · Axel Lin
Quoted 7 lines

hi Liam,

Quoted 1 line

Applied, Btw is this fix also for 2.6.39 ?

I check this patch again and found this actually is not a bug because MC13xxx_DEFINE explictly defines the order of each entry in the array.

:(

Sorry.

Quoted 2 lines

I've already pushed this into next, can you send a fix asap.

Do you want me to send a patch to revert the change? ( Though I think the change is harmless. )
If yes, I can do it.

Regards,
Axel

Quoted 6 lines

Thanks

Liam