[PATCH] mn10300: time: Provide 64-bit persistent clock time

[PATCH] mn10300: time: Provide 64-bit persistent clock time

[Xunlei Pang]

From: Xunlei Pang <pang.xunlei@linaro.org>

As part of addressing the "y2038 problem" for in-kernel uses,
convert update_persistent_clock() to update_persistent_clock64(),
read_persistent_clock() to read_persistent_clock64() using
timespec64 for MN10300.

Add the common weak version of update_persistent_clock() to make
the compiler happy, since we don't have any update_persistent_clock()
defined for MN10300 after converting it to update_persistent_clock64().

Cc: John Stultz <john.stultz@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Xunlei Pang <pang.xunlei@linaro.org>
---
 arch/mn10300/kernel/rtc.c | 13 ++++++-------
 kernel/time/ntp.c         |  5 +++++
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/mn10300/kernel/rtc.c b/arch/mn10300/kernel/rtc.c
index 48d7058..038ae16 100644
--- a/arch/mn10300/kernel/rtc.c
+++ b/arch/mn10300/kernel/rtc.c
@@ -23,19 +23,19 @@ EXPORT_SYMBOL(rtc_lock);
 /*
  * Read the current RTC time
  */
-void read_persistent_clock(struct timespec *ts)
+void read_persistent_clock64(struct timespec64 *ts)
 {
 	struct rtc_time tm;
 
 	get_rtc_time(&tm);
 
 	ts->tv_nsec = 0;
-	ts->tv_sec = mktime(tm.tm_year, tm.tm_mon, tm.tm_mday,
+	ts->tv_sec = mktime64(tm.tm_year, tm.tm_mon, tm.tm_mday,
 			    tm.tm_hour, tm.tm_min, tm.tm_sec);
 
 	/* if rtc is way off in the past, set something reasonable */
 	if (ts->tv_sec < 0)
-		ts->tv_sec = mktime(2009, 1, 1, 12, 0, 0);
+		ts->tv_sec = mktime64(2009, 1, 1, 12, 0, 0);
 }
 
 /*
@@ -48,7 +48,7 @@ void read_persistent_clock(struct timespec *ts)
  * BUG: This routine does not handle hour overflow properly; it just
  *      sets the minutes. Usually you'll only notice that after reboot!
  */
-static int set_rtc_mmss(unsigned long nowtime)
+static int set_rtc_mmss(time64_t nowtime)
 {
 	unsigned char save_control, save_freq_select;
 	int retval = 0;
@@ -74,8 +74,7 @@ static int set_rtc_mmss(unsigned long nowtime)
 	 * messing with unknown time zones but requires your
 	 * RTC not to be off by more than 15 minutes
 	 */
-	real_seconds = nowtime % 60;
-	real_minutes = nowtime / 60;
+	real_minutes = div_s64_rem(nowtime, 60, &real_seconds);
 	if (((abs(real_minutes - cmos_minutes) + 15) / 30) & 1)
 		/* correct for half hour time zone */
 		real_minutes += 30;
@@ -109,7 +108,7 @@ static int set_rtc_mmss(unsigned long nowtime)
 	return retval;
 }
 
-int update_persistent_clock(struct timespec now)
+int update_persistent_clock64(struct timespec64 now)
 {
 	return set_rtc_mmss(now.tv_sec);
 }
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index fb4d98c..df68cb8 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -487,6 +487,11 @@ out:
 }
 
 #ifdef CONFIG_GENERIC_CMOS_UPDATE
+int __weak update_persistent_clock(struct timespec now)
+{
+	return -ENODEV;
+}
+
 int __weak update_persistent_clock64(struct timespec64 now64)
 {
 	struct timespec now;
-- 
1.9.1

Re: [PATCH] mn10300: time: Provide 64-bit persistent clock time

[John Stultz]

On Mon, Jul 20, 2015 at 5:45 PM, Xunlei Pang <xlpang@126.com> wrote:
> From: Xunlei Pang <pang.xunlei@linaro.org>
>
> As part of addressing the "y2038 problem" for in-kernel uses,
> convert update_persistent_clock() to update_persistent_clock64(),
> read_persistent_clock() to read_persistent_clock64() using
> timespec64 for MN10300.

The arch changes look ok.


> Add the common weak version of update_persistent_clock() to make
> the compiler happy, since we don't have any update_persistent_clock()
> defined for MN10300 after converting it to update_persistent_clock64().

So it wasn't immediately obvious why this was needed (compiler
unhappiness isn't really a good explanation). Looking at it, it seems
that the weak update_persistent_clock64() wants a
update_persistent_clock() call to exist (which probably should have
been added when the weak update_persistent_clock64 was added). So it
looks like even if the arch defines a  update_persistent_clock64(),
the weak one still throws a undefined symbol compiler error, right?

The weak update_persistent_clock() bit should probably be added in a
separate patch,  since its not really tied to this arch change (really
any arch that switches to update_persistent_clock64 would have this
issue, no?).

thanks
-john

Re: [PATCH] mn10300: time: Provide 64-bit persistent clock time

[pang.xunlei]

Hi John,

John Stultz <john.stultz@linaro.org> wrote 2015-07-25 AM 11:24:32:
> Re: [PATCH] mn10300: time: Provide 64-bit persistent clock time
> 
> On Mon, Jul 20, 2015 at 5:45 PM, Xunlei Pang <xlpang@126.com> wrote:
> > From: Xunlei Pang <pang.xunlei@linaro.org>
> >
> > As part of addressing the "y2038 problem" for in-kernel uses,
> > convert update_persistent_clock() to update_persistent_clock64(),
> > read_persistent_clock() to read_persistent_clock64() using
> > timespec64 for MN10300.
> 
> The arch changes look ok.
> 
> 
> > Add the common weak version of update_persistent_clock() to make
> > the compiler happy, since we don't have any update_persistent_clock()
> > defined for MN10300 after converting it to 
update_persistent_clock64().
> 
> So it wasn't immediately obvious why this was needed (compiler
> unhappiness isn't really a good explanation). Looking at it, it seems
> that the weak update_persistent_clock64() wants a
> update_persistent_clock() call to exist (which probably should have
> been added when the weak update_persistent_clock64 was added). So it
> looks like even if the arch defines a  update_persistent_clock64(),
> the weak one still throws a undefined symbol compiler error, right?
> 
> The weak update_persistent_clock() bit should probably be added in a
> separate patch,  since its not really tied to this arch change (really
> any arch that switches to update_persistent_clock64 would have this
> issue, no?).

Agree, you're absolutely right. Will do.

Thanks,
-Xunlei

> 
> thanks
> -john

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.