| Message ID | 1259166736-31006-1-git-send-email-jw@emlix.com |
|---|---|
| State | Accepted |
| Headers | show |
I'm thinking that patches 1 and 2 are 2.6.32 material?
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.
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.
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 */
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(-)