From patchwork Mon Jun 18 14:05:16 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 138950 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp3997169lji; Mon, 18 Jun 2018 07:07:13 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKqPP6Xixwu5Pu3LYHK7eiYzF3eWND6tWgEjh5VVqBJjliPyjtYGkepe2tIf8/xj3RrPP0l X-Received: by 2002:a63:778b:: with SMTP id s133-v6mr10896887pgc.400.1529330833223; Mon, 18 Jun 2018 07:07:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529330833; cv=none; d=google.com; s=arc-20160816; b=jnecLx3OM0flKBoAzhG7VVGhHXHUrm3VfpOOAYdOJTYBEn1pLYtznt3jRgOzGFSJwv oB7ZbDtyZ7mIMlbsyTl86MyT3dAP+D8rVwjuEE42OWJ2M54p7szwZksFA+tZWM57ssDZ lKYxVfyc0Uvga9lpiem0DUtfUILFjuU2obnRAOrIURoqLro70afHd7dhAubW3RhcSZjE 7hBRgNsCy3iEyyrlqFGrSDECDuu3LyE2resi9pqGy2HKYo+Uqsjl9IMWienCfLo/KGEV JTJ8HRHGzgSWoLSF83ew7zcdb2lXnjgT6Zq2UMwkSWsBcTugQY898LjyMBlhH6vVbihs 0lIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=H0zPgmokE0PO6kzILqbM0IvUfjD7eD1/G3DIPyR+UX8=; b=UihE7ssKyIenohF9BDyXyywfsQOE6tqiukHGkgZxCvb5h9Zl5p2AGrJNmGEB1VuYIv VN8Ldh0DowMrobIK42rSVTlyuMpz/G+lETE6aOGOClV8FC5X0tWAOep0kAe/UEx1/K+r NBYcZUmD8+b89COgUUhggjKD1S5qC/ce/I46E48afB3BKlTRd58JEIolD1bZckJh1S21 JDDDFPJKkyvXaoJTOo+1F/HeGMIju9fQpVKy+H01h+JXtSc9GmvJ5XWZ+tE6OdS3LIWc oXK18OFCDIFKzJfcfcJB3kmAb5CG73aH69WOUx+XVOGfZh4OxKybxvJTWYSEH4TZfMbO zfwA== 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 g17-v6si14607043plo.355.2018.06.18.07.07.12; Mon, 18 Jun 2018 07:07:13 -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 S934657AbeFROHL (ORCPT + 30 others); Mon, 18 Jun 2018 10:07:11 -0400 Received: from mout.kundenserver.de ([212.227.126.134]:50317 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932860AbeFROHH (ORCPT ); Mon, 18 Jun 2018 10:07:07 -0400 Received: from wuerfel.lan ([95.208.111.237]) by mrelayeu.kundenserver.de (mreue005 [212.227.15.129]) with ESMTPA (Nemesis) id 0MfDvq-1fsbnv22xO-00OkyB; Mon, 18 Jun 2018 16:05:37 +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 1/3] powerpc: mac: fix rtc read functions Date: Mon, 18 Jun 2018 16:05:16 +0200 Message-Id: <20180618140518.2920804-1-arnd@arndb.de> X-Mailer: git-send-email 2.9.0 X-Provags-ID: V03:K1:qw0DyR+gpzEw843/ptQGa6wwShb3h3BNudQco/SiKzF5yUUk/IY qLziZsVSYqGEmXJhRnsl+nqnUSUXsPoJhZuK7yspQcug116WrWM5y1EHSKdSKC0aNmcr0UR tD5srfzkiG86sOFeQQnmXsscuB7Wi28ZopYvaISyXZJxxOLLvGkATk7F8eowWB+MHuf4j+x xaboq2b4YaX6JCbXeRKMw== X-UI-Out-Filterresults: notjunk:1; V01:K0:d1MntMH0Q9U=:LGB6oG6CgQZPSS4MEd5lMO doL8NURgPUXBDkYnarAjASTHF5fiFbYKxQFQFVUuuOzRWBPoFbCGrQNKmQmMiYZ03xje467QH sStwLQ1Uiv+NF0fJI/v4a2lZ/9WwtUGoqso25LN/aHdews4+9AOjrjeB2EZDDM2h4m/Jahi5p 770MVfGIjwvgpLG50HfBqprm0yzrcV69jyIiaKrkGP7Lm1BCOLHcEbr+IXSuHHuo5AyKIGKgk 9sITAvLijPcvHxvksNAc4LPwH4iKQZN7Rx3oUCsBSCrvzKx+gsJYOiNQqzWUNBuHgLb44+vK5 nHJfEOtooeORShp7n2JWapfvT2U8AXdrF6CS4elvY8tYK8apjT83i2VBSV2dXOlht9W1kVpQY 5GtGDEJPk6TVNBUIrK000UQSoCNA+mj3l9ghoIlG6YEBh2EvBLgblAHMSrE0Ra+pOeLCkbTTr +F+rle0/PdogRL0mZG1ncgl28pc0gHGctTsCZYHkLjTv7R0iGhTc6VuoJdunOoe3zBydOY3L5 cvMdjzMogwRZOzTepY8iULGNXUcZHgyMmSvhawNERojkeawk1L/e5LQcKwsrwy5OK6g+Hn6aL +u/fYtTyxCiszjCJEchTJNcdiFWU+QKffFMhx9vJsZtsNI/Q8wfAQJy+5v8Yqym6QJQuRe9iq /cOo4D5t4YpW/68S7knD0Y6ji11qDQ8URgUsi1h1bYjEo43jpcOoh1VRxbN8YOwMHWJE= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As Mathieu pointed out, my conversion to time64_t was incorrect and resulted in negative times to be read from the RTC. The problem is that during the conversion from a byte array to a time64_t, the 'unsigned char' variable holding the top byte gets turned into a negative signed 32-bit integer before being assigned to the 64-bit variable for any times after 1972. This changes the logic to cast to an unsigned 32-bit number first for the Macintosh time and then convert that to the Unix time, which then gives us a time in the documented 1904..2040 year range. I decided not to use the longer 1970..2106 range that other drivers use, for consistency with the literal interpretation of the register, but that could be easily changed if we decide we want to support any Mac after 2040. Just to be on the safe side, I'm also adding a WARN_ON that will trigger if either the year 2040 has come and is observed by this driver, or we run into an RTC that got set back to a pre-1970 date for some reason (the two are indistinguishable). The same code exists in arch/m68k/ and is patched in an identical way now in a separate patch. Fixes: 5bfd643583b2 ("powerpc: use time64_t in read_persistent_clock") Reported-by: Mathieu Malaterre Signed-off-by: Arnd Bergmann --- arch/powerpc/platforms/powermac/time.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) -- 2.9.0 diff --git a/arch/powerpc/platforms/powermac/time.c b/arch/powerpc/platforms/powermac/time.c index 7c968e46736f..173a80630169 100644 --- a/arch/powerpc/platforms/powermac/time.c +++ b/arch/powerpc/platforms/powermac/time.c @@ -42,7 +42,11 @@ #define DBG(x...) #endif -/* Apparently the RTC stores seconds since 1 Jan 1904 */ +/* + * 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 /* @@ -97,8 +101,11 @@ static time64_t cuda_get_time(void) if (req.reply_len != 7) printk(KERN_ERR "cuda_get_time: got %d byte reply\n", req.reply_len); - now = (req.reply[3] << 24) + (req.reply[4] << 16) - + (req.reply[5] << 8) + req.reply[6]; + now = (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(now < RTC_OFFSET); + return now - RTC_OFFSET; } @@ -140,8 +147,12 @@ static time64_t pmu_get_time(void) if (req.reply_len != 4) printk(KERN_ERR "pmu_get_time: got %d byte reply from PMU\n", req.reply_len); - now = (req.reply[0] << 24) + (req.reply[1] << 16) - + (req.reply[2] << 8) + req.reply[3]; + now = (u32)((req.reply[0] << 24) + (req.reply[1] << 16) + + (req.reply[2] << 8) + req.reply[3]); + + /* it's either after year 2040, or the RTC has gone backwards */ + WARN_ON(now < RTC_OFFSET); + return now - RTC_OFFSET; }