Patchwork [1/3] rtc-x1205: fix rtc_time to y2k register value conversion

login
register
mail settings
Submitter Johannes Weiner
Date Nov. 25, 2009, 4:32 p.m.
Message ID <1259166736-31006-1-git-send-email-jw@emlix.com>
Download mbox | patch
Permalink /patch/39322/
State Under Review
Headers show

Comments

Johannes Weiner - Nov. 25, 2009, 4:32 p.m.
The possible CCR_Y2K register values are 19 or 20 and struct
rtc_time's tm_year is in years since 1900.

The function translating rtc_time to register values assumes tm_year
to be years since first christmas, though, and we end up storing 0 or
1 in the CCR_Y2K register, which the hardware does not refuse to do.

A subsequent probing of the clock fails due to the invalid value range
in the register, though.

[ And if it didn't, reading the clock would yield a bogus year because
  the function translating registers to tm_year is assuming a register
  value of 19 or 20. ]

This fixes the conversion from years since 1900 in tm_year to the
corresponding CCR_Y2K value of 19 or 20.

Signed-off-by: Johannes Weiner <jw@emlix.com>
---
 drivers/rtc/rtc-x1205.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Andrew Morton - Nov. 25, 2009, 10:11 p.m.
I'm thinking that patches 1 and 2 are 2.6.32 material?
Johannes Weiner - Nov. 26, 2009, 1:02 a.m.
On Wed, Nov 25, 2009 at 02:11:00PM -0800, Andrew Morton wrote:
> I'm thinking that patches 1 and 2 are 2.6.32 material?

Yeah, I think so too, although I hope we can get feedback from the
authors beforehand.

Because #1 looks obvious to me and makes the driver at all usable for
me but the code has been like that since the initial merge in 2006.
So either

	a) nobody ever set the date with this thing,
	b) every embedded linux company has its own private patch or
	c) I am missing something,

where likelyhood is in reverse order.  That makes me feel slightly
uncomfortable.
Alessandro Zummo - Nov. 26, 2009, 9:40 p.m.
On Thu, 26 Nov 2009 02:02:34 +0100
Johannes Weiner <jw@emlix.com> wrote:

> eah, I think so too, although I hope we can get feedback from the
> authors beforehand.
> 
> Because #1 looks obvious to me and makes the driver at all usable for
> me but the code has been like that since the initial merge in 2006.
> So either
> 
> 	a) nobody ever set the date with this thing,
> 	b) every embedded linux company has its own private patch or
> 	c) I am missing something,
> 
> where likelyhood is in reverse order.  That makes me feel slightly
> uncomfortable.

 The last time I used an x1205 it worked nicely. It's been two or three
 years since. However the datasheet says 0x19 o 0x20 so your patch
 looks good.

Patch

diff --git a/drivers/rtc/rtc-x1205.c b/drivers/rtc/rtc-x1205.c
index 310c107..cc9ba47 100644
--- a/drivers/rtc/rtc-x1205.c
+++ b/drivers/rtc/rtc-x1205.c
@@ -195,7 +195,7 @@  static int x1205_set_datetime(struct i2c_client *client, struct rtc_time *tm,
 		/* year, since the rtc epoch*/
 		buf[CCR_YEAR] = bin2bcd(tm->tm_year % 100);
 		buf[CCR_WDAY] = tm->tm_wday & 0x07;
-		buf[CCR_Y2K] = bin2bcd(tm->tm_year / 100);
+		buf[CCR_Y2K] = bin2bcd((tm->tm_year + 1900) / 100);
 	}
 
 	/* If writing alarm registers, set compare bits on registers 0-4 */