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.
Signed-off-by: Axel Lin <[email protected]>
---
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(-)
diff --git a/drivers/regulator/mc13892-regulator.c b/drivers/regulator/mc13892-regulator.c
index 1b8f739..ba909cb 100644
--- a/drivers/regulator/mc13892-regulator.c
+++ b/drivers/regulator/mc13892-regulator.c
@@ -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,
--
1.7.1
On Thu, May 05, 2011 at 11:32:58PM +0800, Axel Lin wrote:
> 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.
Acked-by: Mark Brown <[email protected]>
On Thu, 2011-05-05 at 23:32 +0800, Axel Lin wrote:
> 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.
>
> Signed-off-by: Axel Lin <[email protected]>
> ---
> 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
hi Liam,
> 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
On Tue, 2011-05-10 at 16:54 +0800, Axel Lin wrote:
> hi Liam,
>
> > 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
2011/5/10 Liam Girdwood <[email protected]>:
> On Tue, 2011-05-10 at 16:54 +0800, Axel Lin wrote:
>> hi Liam,
>>
>> > 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.
>
> 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
>
> Thanks
>
> Liam
>
>