From b65769fc013edb7c2e5fdcd91ea6124ad76168f5 Mon Sep 17 00:00:00 2001 From: Finn Thain Date: Mon, 23 Apr 2018 11:02:57 +1000 Subject: m68k: Fix off-by-one calendar month This fixes a bug in read_persistent_clock() which causes the system clock to lag the Real Time Clock by one month. The problem was noticed on a Mac, but theoretically it must also affect Atari, BVME6000 and Q40. The tm_mon value in the struct rtc_time passed to mach_hwclk() is zero-based, and atari_mste_hwclk(), atari_tt_hwclk(), bvme6000_hwclk(), mac_hwclk() and q40_hwclk() all make this adjustment. Unfortunately, dn_dummy_hwclk(), mvme147_hwclk(), mvme16x_hwclk(), sun3_hwclk() and sun3x_hwclk() fail to decrement tm_mon. Also m68328_hwclk() assumes a one-based tm_mon. Bring these platforms into line and fix read_persistent_clock() so it works correctly on all m68k platforms. The datasheets for the RTC devices found on the affected platforms all confirm that the year is stored as a value in the range 0-99 and the month is stored as a value in the range 1-12. Please refer to the datasheets for MC146818 (Apollo), DS1643 (MVME), ICM7170 (Sun 3) and M48T02 (Sun 3x). Reported-by: Stan Johnson Signed-off-by: Finn Thain Reviewed-by: Arnd Bergmann Signed-off-by: Geert Uytterhoeven --- arch/m68k/mvme16x/config.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'arch/m68k/mvme16x') diff --git a/arch/m68k/mvme16x/config.c b/arch/m68k/mvme16x/config.c index 6fa06d4d16bf..4ffd9ef98de4 100644 --- a/arch/m68k/mvme16x/config.c +++ b/arch/m68k/mvme16x/config.c @@ -400,12 +400,14 @@ int mvme16x_hwclk(int op, struct rtc_time *t) if (!op) { rtc->ctrl = RTC_READ; t->tm_year = bcd2int (rtc->bcd_year); - t->tm_mon = bcd2int (rtc->bcd_mth); + t->tm_mon = bcd2int(rtc->bcd_mth) - 1; t->tm_mday = bcd2int (rtc->bcd_dom); t->tm_hour = bcd2int (rtc->bcd_hr); t->tm_min = bcd2int (rtc->bcd_min); t->tm_sec = bcd2int (rtc->bcd_sec); rtc->ctrl = 0; + if (t->tm_year < 70) + t->tm_year += 100; } return 0; } -- cgit v1.2.3