Re: [PATCH] m68k: Fix off-by-one calendar month

Re: [PATCH] m68k: Fix off-by-one calendar month

[Arnd Bergmann]

On Mon, Apr 23, 2018 at 3:02 AM, Finn Thain <fthain@telegraphics.com.au> wrote:

> diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
> index 97dd4e26f234..6b4389a6e8ea 100644
> --- a/arch/m68k/kernel/time.c
> +++ b/arch/m68k/kernel/time.c
> @@ -74,17 +74,17 @@ static irqreturn_t timer_interrupt(int irq, void *dummy)
>  void read_persistent_clock(struct timespec *ts)
>  {
>         struct rtc_time time;
> +
>         ts->tv_sec = 0;
>         ts->tv_nsec = 0;
>
> -       if (mach_hwclk) {
> -               mach_hwclk(0, &time);
> +       if (!mach_hwclk)
> +               return;
> +
> +       mach_hwclk(0, &time);
>
> -               if ((time.tm_year += 1900) < 1970)
> -                       time.tm_year += 100;
> -               ts->tv_sec = mktime(time.tm_year, time.tm_mon, time.tm_mday,
> -                                     time.tm_hour, time.tm_min, time.tm_sec);
> -       }
> +       ts->tv_sec = mktime(time.tm_year + 1900, time.tm_mon + 1, time.tm_mday,
> +                           time.tm_hour, time.tm_min, time.tm_sec);
>  }

This clashes with a patch I had planned to submit today, but otherwise
looks correct and. I'll respin my patch on top of yours. Since I've taken
a good look at your changes in the meantime

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

      Arnd

Re: [PATCH] m68k: Fix off-by-one calendar month

[Finn Thain]

On Mon, 23 Apr 2018, Arnd Bergmann wrote:

> 
> This clashes with a patch I had planned to submit today, but otherwise
> looks correct and. I'll respin my patch on top of yours. Since I've taken
> a good look at your changes in the meantime
> 
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> 

Thanks, Arnd.

Geert, let me know if I should re-send this with the "reviewed-by" from 
Arnd and "cc" to stable...

-- 

>       Arnd

Re: [PATCH] m68k: Fix off-by-one calendar month

[Geert Uytterhoeven]

Hi Finn,

On Tue, Apr 24, 2018 at 1:39 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Mon, 23 Apr 2018, Arnd Bergmann wrote:
>> This clashes with a patch I had planned to submit today, but otherwise
>> looks correct and. I'll respin my patch on top of yours. Since I've taken
>> a good look at your changes in the meantime
>>
>> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks, Arnd.
>
> Geert, let me know if I should re-send this with the "reviewed-by" from
> Arnd and "cc" to stable...

Thanks, there's no need for that.
I will add the Reviewed-by while applying, and stable will pick it up based on
the "fix" in the one-line summary.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] m68k: Fix off-by-one calendar month

[Geert Uytterhoeven]

Hi Finn,

On Thu, Apr 26, 2018 at 10:23 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
> I just noticed that my patch overlooked m68328_hwclk(). Like the other
> platforms, this one also needs tm_mon decremented.

I had noticed, but this is a fake date anyway.
So I don't know if it's worth fixing...

> Geert, can you amend the commit in your tree or should I submit this
> separately?

If it's worth fixing, please submit it separately.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] m68k: Fix off-by-one calendar month

[Finn Thain]

I just noticed that my patch overlooked m68328_hwclk(). Like the other 
platforms, this one also needs tm_mon decremented.

Geert, can you amend the commit in your tree or should I submit this 
separately?

diff --git a/arch/m68k/68000/timers.c b/arch/m68k/68000/timers.c
index 252455bce144..71ddb4c98726 100644
--- a/arch/m68k/68000/timers.c
+++ b/arch/m68k/68000/timers.c
@@ -125,7 +125,9 @@ int m68328_hwclk(int set, struct rtc_time *t)
 {
 	if (!set) {
 		long now = RTCTIME;
-		t->tm_year = t->tm_mon = t->tm_mday = 1;
+		t->tm_year = 1;
+		t->tm_mon = 0;
+		t->tm_mday = 1;
 		t->tm_hour = (now >> 24) % 24;
 		t->tm_min = (now >> 16) % 60;
 		t->tm_sec = now % 60;

-- 

Re: [PATCH] m68k: Fix off-by-one calendar month

[Finn Thain]

On Tue, 24 Apr 2018, Geert Uytterhoeven wrote:

> 
> Upon closer look, it's not, as Amiga no longer provides mach_hwclk().

Right, Amiga is not affected. However, if you disable CONFIG_RTCHCTOSYS or 
CONFIG_RTC_DRV_GENERIC, you should see an improvement on Atari, BVME6000, 
Mac and Q40.

-- 

Re: [PATCH] m68k: Fix off-by-one calendar month

[Arnd Bergmann]

On Tue, Apr 24, 2018 at 12:37 PM, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 24/04/2018 12:06:30+0200, Geert Uytterhoeven wrote:
>>
>> On Mon, Apr 23, 2018 at 3:02 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
>> <snip>
>>
>> > --- a/arch/m68k/kernel/time.c
>> > +++ b/arch/m68k/kernel/time.c
>> > @@ -74,17 +74,17 @@ static irqreturn_t timer_interrupt(int irq, void *dummy)
>> >  void read_persistent_clock(struct timespec *ts)
>> >  {
>> >         struct rtc_time time;
>> > +
>> >         ts->tv_sec = 0;
>> >         ts->tv_nsec = 0;
>> >
>> > -       if (mach_hwclk) {
>> > -               mach_hwclk(0, &time);
>> > +       if (!mach_hwclk)
>> > +               return;
>> > +
>> > +       mach_hwclk(0, &time);
>> >
>> > -               if ((time.tm_year += 1900) < 1970)
>> > -                       time.tm_year += 100;
>
> Note that this change may break existing users.

I had the same thought but then realized that the +=100 logic was simply
moved into the individual drivers, so the behavior should not change here.

> I'm perfectly fine with
> it as doing this is generally wrong anyway and this is something I'd
> like to see eliminated.

I think most of the m68k RTC hardware uses two-digit BCD year numbers,
so we can't just remove it without implementing something else to
lift the RTC into the current century.

       Arnd

Re: [PATCH] m68k: Fix off-by-one calendar month

[Alexandre Belloni]

On 24/04/2018 12:51:32+0200, Geert Uytterhoeven wrote:
> > Note that this change may break existing users. I'm perfectly fine with
> > it as doing this is generally wrong anyway and this is something I'd
> > like to see eliminated.
> 
> The year handling is moved into the various mach_hwclk() implementations
> in the same patch (in the "<snip>" part).
> 

Ok.

> >
> >> > -               ts->tv_sec = mktime(time.tm_year, time.tm_mon, time.tm_mday,
> >> > -                                     time.tm_hour, time.tm_min, time.tm_sec);
> >> > -       }
> >> > +       ts->tv_sec = mktime(time.tm_year + 1900, time.tm_mon + 1, time.tm_mday,
> >> > +                           time.tm_hour, time.tm_min, time.tm_sec);
> >>
> >> That might explain why my Amiga spends so much time on file system checks
> >> since I wrote the rp5c01 RTC driver...
> 
> Upon closer look, it's not, as Amiga no longer provides mach_hwclk().
> So it must be due to fsck running before the rtc module is loaded?
> 

Quite possibly, an easy way to know is to check the system time beofre
fsck runs.


-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH] m68k: Fix off-by-one calendar month

[Geert Uytterhoeven]

Hi Alexandre,

On Tue, Apr 24, 2018 at 12:37 PM, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 24/04/2018 12:06:30+0200, Geert Uytterhoeven wrote:
>> On Mon, Apr 23, 2018 at 3:02 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
>> > 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.
>> >
>> > 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 <userm57@yahoo.com>
>> > Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
>>
>> Thanks, applied and queued for v4.18.
>>
>> <snip>
>>
>> > --- a/arch/m68k/kernel/time.c
>> > +++ b/arch/m68k/kernel/time.c
>> > @@ -74,17 +74,17 @@ static irqreturn_t timer_interrupt(int irq, void *dummy)
>> >  void read_persistent_clock(struct timespec *ts)
>> >  {
>> >         struct rtc_time time;
>> > +
>> >         ts->tv_sec = 0;
>> >         ts->tv_nsec = 0;
>> >
>> > -       if (mach_hwclk) {
>> > -               mach_hwclk(0, &time);
>> > +       if (!mach_hwclk)
>> > +               return;
>> > +
>> > +       mach_hwclk(0, &time);
>> >
>> > -               if ((time.tm_year += 1900) < 1970)
>> > -                       time.tm_year += 100;
>
> Note that this change may break existing users. I'm perfectly fine with
> it as doing this is generally wrong anyway and this is something I'd
> like to see eliminated.

The year handling is moved into the various mach_hwclk() implementations
in the same patch (in the "<snip>" part).

>
>> > -               ts->tv_sec = mktime(time.tm_year, time.tm_mon, time.tm_mday,
>> > -                                     time.tm_hour, time.tm_min, time.tm_sec);
>> > -       }
>> > +       ts->tv_sec = mktime(time.tm_year + 1900, time.tm_mon + 1, time.tm_mday,
>> > +                           time.tm_hour, time.tm_min, time.tm_sec);
>>
>> That might explain why my Amiga spends so much time on file system checks
>> since I wrote the rp5c01 RTC driver...

Upon closer look, it's not, as Amiga no longer provides mach_hwclk().
So it must be due to fsck running before the rtc module is loaded?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] m68k: Fix off-by-one calendar month

[Alexandre Belloni]

On 24/04/2018 12:06:30+0200, Geert Uytterhoeven wrote:
> Hi Finn,
> 
> On Mon, Apr 23, 2018 at 3:02 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
> > 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.
> >
> > 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 <userm57@yahoo.com>
> > Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
> 
> Thanks, applied and queued for v4.18.
> 
> <snip>
> 
> > --- a/arch/m68k/kernel/time.c
> > +++ b/arch/m68k/kernel/time.c
> > @@ -74,17 +74,17 @@ static irqreturn_t timer_interrupt(int irq, void *dummy)
> >  void read_persistent_clock(struct timespec *ts)
> >  {
> >         struct rtc_time time;
> > +
> >         ts->tv_sec = 0;
> >         ts->tv_nsec = 0;
> >
> > -       if (mach_hwclk) {
> > -               mach_hwclk(0, &time);
> > +       if (!mach_hwclk)
> > +               return;
> > +
> > +       mach_hwclk(0, &time);
> >
> > -               if ((time.tm_year += 1900) < 1970)
> > -                       time.tm_year += 100;

Note that this change may break existing users. I'm perfectly fine with
it as doing this is generally wrong anyway and this is something I'd
like to see eliminated.

> > -               ts->tv_sec = mktime(time.tm_year, time.tm_mon, time.tm_mday,
> > -                                     time.tm_hour, time.tm_min, time.tm_sec);
> > -       }
> > +       ts->tv_sec = mktime(time.tm_year + 1900, time.tm_mon + 1, time.tm_mday,
> > +                           time.tm_hour, time.tm_min, time.tm_sec);
> 
> That might explain why my Amiga spends so much time on file system checks
> since I wrote the rp5c01 RTC driver...
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH] m68k: Fix off-by-one calendar month

[Geert Uytterhoeven]

Hi Finn,

On Mon, Apr 23, 2018 at 3:02 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
> 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.
>
> 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 <userm57@yahoo.com>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>

Thanks, applied and queued for v4.18.

<snip>

> --- a/arch/m68k/kernel/time.c
> +++ b/arch/m68k/kernel/time.c
> @@ -74,17 +74,17 @@ static irqreturn_t timer_interrupt(int irq, void *dummy)
>  void read_persistent_clock(struct timespec *ts)
>  {
>         struct rtc_time time;
> +
>         ts->tv_sec = 0;
>         ts->tv_nsec = 0;
>
> -       if (mach_hwclk) {
> -               mach_hwclk(0, &time);
> +       if (!mach_hwclk)
> +               return;
> +
> +       mach_hwclk(0, &time);
>
> -               if ((time.tm_year += 1900) < 1970)
> -                       time.tm_year += 100;
> -               ts->tv_sec = mktime(time.tm_year, time.tm_mon, time.tm_mday,
> -                                     time.tm_hour, time.tm_min, time.tm_sec);
> -       }
> +       ts->tv_sec = mktime(time.tm_year + 1900, time.tm_mon + 1, time.tm_mday,
> +                           time.tm_hour, time.tm_min, time.tm_sec);

That might explain why my Amiga spends so much time on file system checks
since I wrote the rp5c01 RTC driver...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH] m68k: Fix off-by-one calendar month

[Finn Thain]

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.

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 <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
 arch/m68k/apollo/config.c  |  8 +++++---
 arch/m68k/kernel/time.c    | 14 +++++++-------
 arch/m68k/mvme147/config.c |  4 +++-
 arch/m68k/mvme16x/config.c |  4 +++-
 arch/m68k/sun3/intersil.c  |  8 +++++---
 arch/m68k/sun3x/time.c     |  8 +++++---
 6 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/arch/m68k/apollo/config.c b/arch/m68k/apollo/config.c
index 0d27706f14d4..8a5f98904af3 100644
--- a/arch/m68k/apollo/config.c
+++ b/arch/m68k/apollo/config.c
@@ -221,8 +221,10 @@ int dn_dummy_hwclk(int op, struct rtc_time *t) {
     t->tm_hour=rtc->hours;
     t->tm_mday=rtc->day_of_month;
     t->tm_wday=rtc->day_of_week;
-    t->tm_mon=rtc->month;
+    t->tm_mon = rtc->month - 1;
     t->tm_year=rtc->year;
+    if (t->tm_year < 70)
+    	t->tm_year += 100;
   } else {
     rtc->second=t->tm_sec;
     rtc->minute=t->tm_min;
@@ -230,8 +232,8 @@ int dn_dummy_hwclk(int op, struct rtc_time *t) {
     rtc->day_of_month=t->tm_mday;
     if(t->tm_wday!=-1)
       rtc->day_of_week=t->tm_wday;
-    rtc->month=t->tm_mon;
-    rtc->year=t->tm_year;
+    rtc->month = t->tm_mon + 1;
+    rtc->year = t->tm_year % 100;
   }
 
   return 0;
diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
index 97dd4e26f234..6b4389a6e8ea 100644
--- a/arch/m68k/kernel/time.c
+++ b/arch/m68k/kernel/time.c
@@ -74,17 +74,17 @@ static irqreturn_t timer_interrupt(int irq, void *dummy)
 void read_persistent_clock(struct timespec *ts)
 {
 	struct rtc_time time;
+
 	ts->tv_sec = 0;
 	ts->tv_nsec = 0;
 
-	if (mach_hwclk) {
-		mach_hwclk(0, &time);
+	if (!mach_hwclk)
+		return;
+
+	mach_hwclk(0, &time);
 
-		if ((time.tm_year += 1900) < 1970)
-			time.tm_year += 100;
-		ts->tv_sec = mktime(time.tm_year, time.tm_mon, time.tm_mday,
-				      time.tm_hour, time.tm_min, time.tm_sec);
-	}
+	ts->tv_sec = mktime(time.tm_year + 1900, time.tm_mon + 1, time.tm_mday,
+			    time.tm_hour, time.tm_min, time.tm_sec);
 }
 
 #if defined(CONFIG_ARCH_USES_GETTIMEOFFSET) && IS_ENABLED(CONFIG_RTC_DRV_GENERIC)
diff --git a/arch/m68k/mvme147/config.c b/arch/m68k/mvme147/config.c
index 8778612d1f31..f8a710fd84cd 100644
--- a/arch/m68k/mvme147/config.c
+++ b/arch/m68k/mvme147/config.c
@@ -153,12 +153,14 @@ int mvme147_hwclk(int op, struct rtc_time *t)
 	if (!op) {
 		m147_rtc->ctrl = RTC_READ;
 		t->tm_year = bcd2int (m147_rtc->bcd_year);
-		t->tm_mon  = bcd2int (m147_rtc->bcd_mth);
+		t->tm_mon  = bcd2int(m147_rtc->bcd_mth) - 1;
 		t->tm_mday = bcd2int (m147_rtc->bcd_dom);
 		t->tm_hour = bcd2int (m147_rtc->bcd_hr);
 		t->tm_min  = bcd2int (m147_rtc->bcd_min);
 		t->tm_sec  = bcd2int (m147_rtc->bcd_sec);
 		m147_rtc->ctrl = 0;
+		if (t->tm_year < 70)
+			t->tm_year += 100;
 	}
 	return 0;
 }
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;
 }
diff --git a/arch/m68k/sun3/intersil.c b/arch/m68k/sun3/intersil.c
index 2cd0bcbe6f30..d911070af02a 100644
--- a/arch/m68k/sun3/intersil.c
+++ b/arch/m68k/sun3/intersil.c
@@ -48,9 +48,9 @@ int sun3_hwclk(int set, struct rtc_time *t)
 		todintersil->hour = t->tm_hour;
 		todintersil->minute = t->tm_min;
 		todintersil->second = t->tm_sec;
-		todintersil->month = t->tm_mon;
+		todintersil->month = t->tm_mon + 1;
 		todintersil->day = t->tm_mday;
-		todintersil->year = t->tm_year - 68;
+		todintersil->year = (t->tm_year - 68) % 100;
 		todintersil->weekday = t->tm_wday;
 	} else {
 		/* read clock */
@@ -58,10 +58,12 @@ int sun3_hwclk(int set, struct rtc_time *t)
 		t->tm_hour = todintersil->hour;
 		t->tm_min = todintersil->minute;
 		t->tm_sec = todintersil->second;
-		t->tm_mon = todintersil->month;
+		t->tm_mon = todintersil->month - 1;
 		t->tm_mday = todintersil->day;
 		t->tm_year = todintersil->year + 68;
 		t->tm_wday = todintersil->weekday;
+		if (t->tm_year < 70)
+			t->tm_year += 100;
 	}
 
 	intersil_clock->cmd_reg = START_VAL;
diff --git a/arch/m68k/sun3x/time.c b/arch/m68k/sun3x/time.c
index 7a2c53d9f779..047e2bcee3d7 100644
--- a/arch/m68k/sun3x/time.c
+++ b/arch/m68k/sun3x/time.c
@@ -52,8 +52,8 @@ int sun3x_hwclk(int set, struct rtc_time *t)
 		h->hour = bin2bcd(t->tm_hour);
 		h->wday = bin2bcd(t->tm_wday);
 		h->mday = bin2bcd(t->tm_mday);
-		h->month = bin2bcd(t->tm_mon);
-		h->year = bin2bcd(t->tm_year);
+		h->month = bin2bcd(t->tm_mon + 1);
+		h->year = bin2bcd(t->tm_year % 100);
 		h->csr &= ~C_WRITE;
 	} else {
 		h->csr |= C_READ;
@@ -62,9 +62,11 @@ int sun3x_hwclk(int set, struct rtc_time *t)
 		t->tm_hour = bcd2bin(h->hour);
 		t->tm_wday = bcd2bin(h->wday);
 		t->tm_mday = bcd2bin(h->mday);
-		t->tm_mon = bcd2bin(h->month);
+		t->tm_mon = bcd2bin(h->month) - 1;
 		t->tm_year = bcd2bin(h->year);
 		h->csr &= ~C_READ;
+		if (t->tm_year < 70)
+			t->tm_year += 100;
 	}
 
 	local_irq_restore(flags);
-- 
2.16.1