rtc-pcf85063 driver bug in pcf85063_stop_clock()

rtc-pcf85063 driver bug in pcf85063_stop_clock()

[Craig McQueen]

The function pcf85063_stop_clock() is intended to provide the value of the Control_1 register via the pointer ctrl1.

However, it's really providing the return value of the last i2c_smbus_write_byte_data() call, i.e., zero. So the register value needs to be saved in a separate local variable other than ret. Or, the line *ctrl1 = ret; needs to be moved up to be above the last i2c_smbus_write_byte_data() call.

-- 
Craig McQueen

Re: rtc-pcf85063 driver bug in pcf85063_stop_clock()

[Alexandre Belloni]

Hello,

On 11/10/2018 06:53:15+0000, Craig McQueen wrote:
> The function pcf85063_stop_clock() is intended to provide the value of the Control_1 register via the pointer ctrl1.
> 
> However, it's really providing the return value of the last i2c_smbus_write_byte_data() call, i.e., zero. So the register value needs to be saved in a separate local variable other than ret. Or, the line *ctrl1 = ret; needs to be moved up to be above the last i2c_smbus_write_byte_data() call.
> 

Isn't that fixed by http://patchwork.ozlabs.org/patch/944107/ ?

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

RE: rtc-pcf85063 driver bug in pcf85063_stop_clock()

[Craig McQueen]

I wrote:
> 
> The function pcf85063_stop_clock() is intended to provide the value of the
> Control_1 register via the pointer ctrl1.
> 
> However, it's really providing the return value of the last
> i2c_smbus_write_byte_data() call, i.e., zero. So the register value needs to
> be saved in a separate local variable other than ret. Or, the line *ctrl1 = ret;
> needs to be moved up to be above the last i2c_smbus_write_byte_data()
> call.

I'd like to follow up on this. I could perhaps submit a patch, but I'm not sure what is the best fix for this bug. Any recommendations?

-- 
Craig McQueen

Re: rtc-pcf85063 driver bug in pcf85063_stop_clock()

[Alexandre Belloni]

Hello,

On 19/11/2018 22:56:07+0000, Craig McQueen wrote:
> I wrote:
> > 
> > The function pcf85063_stop_clock() is intended to provide the value of the
> > Control_1 register via the pointer ctrl1.
> > 
> > However, it's really providing the return value of the last
> > i2c_smbus_write_byte_data() call, i.e., zero. So the register value needs to
> > be saved in a separate local variable other than ret. Or, the line *ctrl1 = ret;
> > needs to be moved up to be above the last i2c_smbus_write_byte_data()
> > call.
> 
> I'd like to follow up on this. I could perhaps submit a patch, but I'm not sure what is the best fix for this bug. Any recommendations?
> 

I replied a while ago, isn't that fixed by:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/rtc/rtc-pcf85063.c?id=ec9cf1b7a6af2c0cffaa887351e7c7acced5290e


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

RE: rtc-pcf85063 driver bug in pcf85063_stop_clock()

[Craig McQueen]

Alexandre Belloni wrote:
> 
> Hello,
> 
> On 19/11/2018 22:56:07+0000, Craig McQueen wrote:
> > I wrote:
> > >
> > > The function pcf85063_stop_clock() is intended to provide the value
> > > of the
> > > Control_1 register via the pointer ctrl1.
> > >
> > > However, it's really providing the return value of the last
> > > i2c_smbus_write_byte_data() call, i.e., zero. So the register value
> > > needs to be saved in a separate local variable other than ret. Or,
> > > the line *ctrl1 = ret; needs to be moved up to be above the last
> > > i2c_smbus_write_byte_data() call.
> >
> > I'd like to follow up on this. I could perhaps submit a patch, but I'm not sure
> what is the best fix for this bug. Any recommendations?
> >
> 
> I replied a while ago, isn't that fixed by:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/d
> rivers/rtc/rtc-pcf85063.c?id=ec9cf1b7a6af2c0cffaa887351e7c7acced5290e

Thanks, that looks like a fix for the exact problem. I thought I'd checked the master branch for a fix before posting this, but maybe I hadn't fetched the latest that includes that commit.

Sorry I missed your previous reply.

-- 
Craig McQueen