From patchwork Mon Jun 18 14:05:17 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 138948 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp3995620lji; Mon, 18 Jun 2018 07:05:57 -0700 (PDT) X-Google-Smtp-Source: ADUXVKL6obmy/ge9KfRGnv0K6NA6jjFJ4A6qDuCJVE8Nsf693WEVGMbS9gfpYTokdvxjJG51z0k3 X-Received: by 2002:a17:902:7442:: with SMTP id e2-v6mr14527619plt.28.1529330757597; Mon, 18 Jun 2018 07:05:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529330757; cv=none; d=google.com; s=arc-20160816; b=GiNMUQqhhj2Rk0P3P6+kVAMUDAMKRg1lyuAh4lAp8AfjF2kIHDC9hpPZz/PK5F7+RB NZPBoyO1yYqKM4gJHcalj3qQnxH06dCpmK0IQN/F5XzyctIQfRnISDkX9qbqaBg+G4Ip OBmylLDlCrngf6SJPE0lYOmQB3T3ytUZb4Nr+iGpn60pIOnmveX4Dfu09tQb0Xim0/76 tRQByaq7h1Wax7FxSyEIlaPWjDvytdF1JyAceD17inGyiXr6f+Pzadk8vYPTNMVKnQDG o30qKp2ZbO3cM+vp3dXEOtDNXwdMXWQzZp1brVTAkG2xWklF1sxfha2R2XQ2re46cNzt gXoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=NA4GXQ8ek1+4DIGaxZpfRXYSrm+oMWZPdolrJLCjN4o=; b=d8SD8ZmVKQ8peGqd1FrU/QI9//RGzlFsQQBiBXLN+HJA28zhy51oEfrWodyMnge3rR o/4kxAoWGJfBWFfwnOWoGYNfjHeAP5TjW0bYcrr07mTD6lvGMjlZtvX/uhc/8yfVEsmb VcG7DiVUWYZGayjQszEkOKXdlj7aCMmV6Ks+5CuYhHvmAW5yRN4Yu2HJ7IIyv/+Jkiqy ad5zYDfD+DE/SnOEw5LbaiVnxuV0ai2iI9K7mwg8kxL8Oua67evWg98ZdjKoTFZ4NY5Q UukUeWp0EmdNzNS6aWR/+2t7+Jp9Y8hbSVo6RvT7+FtOavvVelPeA0JV18bLUywreO8y AiKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v5-v6si11844373pgs.15.2018.06.18.07.05.57; Mon, 18 Jun 2018 07:05:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934109AbeFROFx (ORCPT + 30 others); Mon, 18 Jun 2018 10:05:53 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:41743 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754321AbeFROFv (ORCPT ); Mon, 18 Jun 2018 10:05:51 -0400 Received: from wuerfel.lan ([95.208.111.237]) by mrelayeu.kundenserver.de (mreue005 [212.227.15.129]) with ESMTPA (Nemesis) id 0MJHCg-1fWYgN3wc6-002qPD; Mon, 18 Jun 2018 16:05:38 +0200 From: Arnd Bergmann To: Paul Mackerras , Michael Ellerman , Geert Uytterhoeven , Joshua Thompson Cc: Mathieu Malaterre , Benjamin Herrenschmidt , Greg Ungerer , linux-m68k@lists.linux-m68k.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, y2038@lists.linaro.org, Meelis Roos , Arnd Bergmann Subject: [PATCH 2/3] m68k: mac: use time64_t in RTC handling Date: Mon, 18 Jun 2018 16:05:17 +0200 Message-Id: <20180618140518.2920804-2-arnd@arndb.de> X-Mailer: git-send-email 2.9.0 In-Reply-To: <20180618140518.2920804-1-arnd@arndb.de> References: <20180618140518.2920804-1-arnd@arndb.de> X-Provags-ID: V03:K1:yPAWylP334m9hyjSidjsp/4YLCfNrVCbDnobHvtjLc31kecuWTj JECzE5tDX25o/7m1pCBNHjI7eNgbckaDgUeSxZNavQff9ljLhpgvAvUyMLGWz+ab8mMwbIJ Q3IpCyNCfHFGF4Q5bD6MiVgPb+N5SpNISLS0KbruleTHPSQt9pzLQVzGmH7dDQ5kOFe9yU1 m6Aeej7RRIOW0PFj2xG5A== X-UI-Out-Filterresults: notjunk:1; V01:K0:1AW0bKD/wCQ=:rv9mdrvRlNGwF4B8FN0Ijb 2/+um6FpjgSUFpDA2wiYRrAuapepLZJ3cYNqA/qk0heuQf4VuKXOecWaXcT35KuH7Mzm9UtuI tLo9X/5MtiHCpdfeUvmwF20E+4Rre1nagM/kxGzWBY92qH9c4DCoNJDoxnHTwlYGM67hLcUUJ ooEZxjwC59zGIlJuLkUsyfvbtGYzsWelTdll6WsUHEBYOOVQIHg3ZuIuS4a68L6jyiKZVv0oc 8CBI6SMVaRk+B1yT4hQdqS1O4LMmqXFUQgz6x6nCK9tofGGdqMJmVKaGynxWAVawm4ek7ghf9 c4N+OHDdprjOczgOC+CYAnppa0qxrvfb8zSpmo5BPuPeCmLq1cZr054Cc8vrJ54qSHHQnWHLf D9aIxiHbSFiLKuTb2NZrGkO5zvKl4wtGh8CRd/kP2ikNjSNwK9A/LAKktPrvUJEKorc0HOI4k WBINp/fe459Xr/12ohgbiLxAf/hSDu/b2lTz3/Whd0ghGZfhga3xouFyEqg/iDV/a1IhHDLs+ cCpMWUYTEseifdf8qiiTDwtTI6W9E9pVpU4etnJZXTjcJr/zpEj+znhOVEBxdiDJr1qZKE431 5FD47oD+tdABnydRCKnhjMsxYbI6kaEm1ilI3PkBc8bTKcZrQ85w8kS1wReIbc7E6r1gRPaMr y/SDb8U/k0yBMASPKpNOW7NO/xLEjwa0H9QFt2Pt4p9G3r7fPFa54tvhSUmaat2ty6Ok= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The real-time clock on m68k (and powerpc) mac systems uses an unsigned 32-bit value starting in 1904, which overflows in 2040, about two years later than everyone else, but this gets wrapped around in the Linux code in 2038 already because of the deprecated usage of time_t and/or long in the conversion. Getting rid of the deprecated interfaces makes it work until 2040 as documented, and it could be easily extended by reinterpreting the resulting time64_t as a positive number. For the moment, I'm adding a WARN_ON() that triggers if we encounter a time before 1970 or after 2040 (the two are indistinguishable). This brings it in line with the corresponding code that we have on powerpc macintosh. Signed-off-by: Arnd Bergmann --- arch/m68k/mac/misc.c | 58 +++++++++++++++++++++++++++++++++------------------- 1 file changed, 37 insertions(+), 21 deletions(-) -- 2.9.0 diff --git a/arch/m68k/mac/misc.c b/arch/m68k/mac/misc.c index c68054361615..b399a0809e18 100644 --- a/arch/m68k/mac/misc.c +++ b/arch/m68k/mac/misc.c @@ -26,33 +26,40 @@ #include -/* Offset between Unix time (1970-based) and Mac time (1904-based) */ +/* Offset between Unix time (1970-based) and Mac time (1904-based). Cuda and PMU + * times wrap in 2040. If we need to handle later times, the read_time functions + * need to be changed to interpret wrapped times as post-2040. */ #define RTC_OFFSET 2082844800 static void (*rom_reset)(void); #ifdef CONFIG_ADB_CUDA -static long cuda_read_time(void) +static time64_t cuda_read_time(void) { struct adb_request req; - long time; + time64_t time; if (cuda_request(&req, NULL, 2, CUDA_PACKET, CUDA_GET_TIME) < 0) return 0; while (!req.complete) cuda_poll(); - time = (req.reply[3] << 24) | (req.reply[4] << 16) | - (req.reply[5] << 8) | req.reply[6]; + time = (u32)((req.reply[3] << 24( | (req.reply[4] << 16) | + (req.reply[5] << 8) | req.reply[6]); + + /* it's either after year 2040, or the RTC has gone backwards */ + WARN_ON(time < RTC_OFFSET); + return time - RTC_OFFSET; } -static void cuda_write_time(long data) +static void cuda_write_time(time64_t data) { struct adb_request req; data += RTC_OFFSET; + data &= 0xffffffff; if (cuda_request(&req, NULL, 6, CUDA_PACKET, CUDA_SET_TIME, (data >> 24) & 0xFF, (data >> 16) & 0xFF, (data >> 8) & 0xFF, data & 0xFF) < 0) @@ -86,26 +93,29 @@ static void cuda_write_pram(int offset, __u8 data) #endif /* CONFIG_ADB_CUDA */ #ifdef CONFIG_ADB_PMU68K -static long pmu_read_time(void) +static time64_t pmu_read_time(void) { struct adb_request req; - long time; + time64_t time; if (pmu_request(&req, NULL, 1, PMU_READ_RTC) < 0) return 0; while (!req.complete) pmu_poll(); - time = (req.reply[1] << 24) | (req.reply[2] << 16) | - (req.reply[3] << 8) | req.reply[4]; + /* it's either after year 2040, or the RTC has gone backwards */ + time = (u32)((req.reply[1] << 24) | (req.reply[2] << 16) | + (req.reply[3] << 8) | req.reply[4]); + return time - RTC_OFFSET; } -static void pmu_write_time(long data) +static void pmu_write_time(time64_t data) { struct adb_request req; data += RTC_OFFSET; + data &= 0xffffffff; if (pmu_request(&req, NULL, 5, PMU_SET_RTC, (data >> 24) & 0xFF, (data >> 16) & 0xFF, (data >> 8) & 0xFF, data & 0xFF) < 0) @@ -269,8 +279,12 @@ static long via_read_time(void) via_pram_command(0x89, &result.cdata[1]); via_pram_command(0x8D, &result.cdata[0]); - if (result.idata == last_result.idata) + if (result.idata == last_result.idata) { + if (result.idata < RTC_OFFSET) + result.idata += 0x100000000ull; + return result.idata - RTC_OFFSET; + } if (++count > 10) break; @@ -291,11 +305,11 @@ static long via_read_time(void) * is basically any machine with Mac II-style ADB. */ -static void via_write_time(long time) +static void via_write_time(time64_t time) { union { __u8 cdata[4]; - long idata; + __u32 idata; } data; __u8 temp; @@ -585,12 +599,15 @@ void mac_reset(void) * This function translates seconds since 1970 into a proper date. * * Algorithm cribbed from glibc2.1, __offtime(). + * + * This is roughly same as rtc_time64_to_tm(), which we should probably + * use here, but it's only available when CONFIG_RTC_LIB is enabled. */ #define SECS_PER_MINUTE (60) #define SECS_PER_HOUR (SECS_PER_MINUTE * 60) #define SECS_PER_DAY (SECS_PER_HOUR * 24) -static void unmktime(unsigned long time, long offset, +static void unmktime(time64_t time, long offset, int *yearp, int *monp, int *dayp, int *hourp, int *minp, int *secp) { @@ -602,11 +619,10 @@ static void unmktime(unsigned long time, long offset, /* Leap years. */ { 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366 } }; - long int days, rem, y, wday, yday; + int days, rem, y, wday, yday; const unsigned short int *ip; - days = time / SECS_PER_DAY; - rem = time % SECS_PER_DAY; + days = div_u64_rem(time, SECS_PER_DAY, &rem); rem += offset; while (rem < 0) { rem += SECS_PER_DAY; @@ -657,7 +673,7 @@ static void unmktime(unsigned long time, long offset, int mac_hwclk(int op, struct rtc_time *t) { - unsigned long now; + time64_t now; if (!op) { /* read */ switch (macintosh_config->adb_type) { @@ -693,8 +709,8 @@ int mac_hwclk(int op, struct rtc_time *t) __func__, t->tm_year + 1900, t->tm_mon + 1, t->tm_mday, t->tm_hour, t->tm_min, t->tm_sec); - now = mktime(t->tm_year + 1900, t->tm_mon + 1, t->tm_mday, - t->tm_hour, t->tm_min, t->tm_sec); + now = mktime64(t->tm_year + 1900, t->tm_mon + 1, t->tm_mday, + t->tm_hour, t->tm_min, t->tm_sec); switch (macintosh_config->adb_type) { case MAC_ADB_IOP: