Received: by 10.192.165.148 with SMTP id m20csp1702500imm; Sat, 5 May 2018 20:07:04 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoEclbgkvLgqf22LksHrul6jxfx6XacKGRsxUy+oZpzlptfHZqGkblTRj2CAxc1QvpMC8rW X-Received: by 2002:a17:902:290a:: with SMTP id g10-v6mr33328937plb.155.1525576024619; Sat, 05 May 2018 20:07:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525576024; cv=none; d=google.com; s=arc-20160816; b=0d7YXq3xJGEFV55jboq5jjlY5UKP28hMw6bargWCO8CMMe+aHz3VkpxN2HhDSGugLE iJZ23kPARYZ7E+RVGEC/fNHFnAmCzueiG5dUkrKJpc7lK1bpPtvLfh8BRKv9tGVGidZC iqCoJs6+f13D7TQYeKP60sTY8UlKzMgLFXPcKx7tLminIvGnITR+pMHxFRU5w5AirMvf ZPgKm0Ga2X4aAM1l4fPKLAfsR5NkbmFfFRkom9bfbQEmOqo9U8K10/RIEuU+zciEyMXi J+xuDqf0xgW2BGsyy5/iVju1zO7vWJW6byU++p94Km9ptznQ5D2xEVcoUhDuksc52ied EJrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=ZaLxQ/yP9Tn1dHEFitr4GXCdTEDWcl6RdFI6jXRG61k=; b=j4WpqYau9vauQvZT4jqt5nkxJmHLr7ZldP38DOEOZcXRdQaB4OTDgzdSdSYq3T2igF Tmq5Sl0x3jOfPEL83P9Rc9zo8ljfBUhcYXVx5H/KX6MioXjnJyLYRYFl7YcvXtcLHxnA +cVQ9YCVN0zHJwda3ALrUHmKm9GeyI7XdFtrkZGK/87BFNO7Sgc1zo+LgzdXNpjCEYFQ OaupbMLwAXQpEg0UFBTf8VfbKy5XrcLlfqmBcKatfXTKiZEsv2OzEmphP32yk/6XrtA4 l+BNKG9Wg9v84006hKvp1C9CxYMvLaSX4IHNHamD24+4XAcWg5zakgfExrvmhF84WyxT Vjcw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=QWABn7r9; 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 r63si19194030pfj.331.2018.05.05.20.06.38; Sat, 05 May 2018 20:07:04 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=QWABn7r9; 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 S1751926AbeEFDEW (ORCPT + 99 others); Sat, 5 May 2018 23:04:22 -0400 Received: from mail-qt0-f196.google.com ([209.85.216.196]:36942 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751833AbeEFDET (ORCPT ); Sat, 5 May 2018 23:04:19 -0400 Received: by mail-qt0-f196.google.com with SMTP id q13-v6so31445200qtp.4 for ; Sat, 05 May 2018 20:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZaLxQ/yP9Tn1dHEFitr4GXCdTEDWcl6RdFI6jXRG61k=; b=QWABn7r9paNawwvjSsbf0ag1xu32x0r6acGzvEMgZieAWEMJFso5JziebtlvEsZXR3 WBk891fe0fLZG8tkNtTfMc7pJaadBrJndBInfAqgmMWppvxtf3018Mmr1omeRPymU5Bi ZRJV2H0S1doCSQk0pf0Bl2Pthc0QFRrTVI4nUqRm8Ppib07HEwC6FsO197ZhH90iyxXH o0MBizHlsBzaLdigUfrwQbjtTt+ci2aClv5hH73i0bG5gxvtK2ikdzaE2hioKOCrSCg5 NCwzZBRoLcVKx7dtvp28bey2vGaa5AwOXHnCU+4r6BGBTSWO3UpLnmuqxwCy6C1Kg+VY qw5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZaLxQ/yP9Tn1dHEFitr4GXCdTEDWcl6RdFI6jXRG61k=; b=MWffh7LY8qBqebEVWNUj+wP4C0UeM4nPWgCrCu9dCiW8TCs5YZWXUcHcG6PJEQL0NC ymGLHxZL0ZM8d7rEBTrMpe5MRrPLm3qnWrdTKmqn89HQOW0+hxOOsISd7JuXVSFlDbqY ajOlQdfSboIUWGK1WRpNhun6l1AdzYPTN8Nu9zcuUzyOQ0omyiFBdybnm7edZQq23Mij +neM6t6jkmUKmhL748siANJrmAgOmfFnknD+uXf/RD/rFdxAI+OO987s2qIwEtqe/TI7 LeVDV17+JWRPOrFPAKTiG/UM3Ge1qFhahzezcDrCjn3PfRAzrzFB7qGNy2JlwYRGmLZ+ /yWw== X-Gm-Message-State: ALQs6tC1F4Fo7w6vtz/aMliOsE2Ft4x+kdg6oWwk7qj9ZaW2y7NVjjY/ pVwFX5p+gZo+LBX2Jg1simERXyhjlQAoDpkzMvw= X-Received: by 2002:a0c:bda4:: with SMTP id n36-v6mr26409930qvg.151.1525575858528; Sat, 05 May 2018 20:04:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.185.3 with HTTP; Sat, 5 May 2018 20:04:18 -0700 (PDT) In-Reply-To: <2d0bcca30f61036e413ba01c686ce6506f187462.1525417306.git.baolin.wang@linaro.org> References: <2d0bcca30f61036e413ba01c686ce6506f187462.1525417306.git.baolin.wang@linaro.org> From: Arnd Bergmann Date: Sat, 5 May 2018 23:04:18 -0400 X-Google-Sender-Auth: 5GLMkONbr88zeF4D7OZDrDugpqY Message-ID: Subject: Re: [PATCH v2 2/2] MIPS: Convert update_persistent_clock() to update_persistent_clock64() To: Baolin Wang Cc: "Maciej W. Rozycki" , Ralf Baechle , James Hogan , chenhc@lemote.com, Kate Stewart , gregkh , Thomas Gleixner , Philippe Ombredanne , Mark Brown , Paul Burton , Heiko Stuebner , Daniel Lezcano , Viresh Kumar , "open list:RALINK MIPS ARCHITECTURE" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 4, 2018 at 3:07 AM, Baolin Wang wrote: > Since struct timespec is not y2038 safe on 32bit machines, this patch > converts update_persistent_clock() to update_persistent_clock64() using > struct timespec64. > > The rtc_mips_set_time() and rtc_mips_set_mmss() interfaces were using > 'unsigned long' type that is not y2038 safe on 32bit machines, moreover > there is only one platform implementing rtc_mips_set_time() and two > platforms implementing rtc_mips_set_mmss(), so we can just make them each > implement update_persistent_clock64() directly, to get that helper out > of the common mips code by removing rtc_mips_set_time() and > rtc_mips_set_mmss() interfaces. > > Signed-off-by: Baolin Wang Looks good overall, but I still found a bug and one minor issue. With those fixed, Acked-by: Arnd Bergmann > diff --git a/arch/mips/dec/time.c b/arch/mips/dec/time.c > index 9e992cf..934db6f 100644 > --- a/arch/mips/dec/time.c > +++ b/arch/mips/dec/time.c > @@ -59,14 +59,15 @@ void read_persistent_clock64(struct timespec64 *ts) > } > > /* > - * In order to set the CMOS clock precisely, rtc_mips_set_mmss has to > + * In order to set the CMOS clock precisely, update_persistent_clock64 has to > * be called 500 ms after the second nowtime has started, because when > * nowtime is written into the registers of the CMOS clock, it will > * jump to the next second precisely 500 ms later. Check the Dallas > * DS1287 data sheet for details. > */ > -int rtc_mips_set_mmss(unsigned long nowtime) > +int update_persistent_clock64(struct timespec64 now) > { > + time64_t nowtime = now.tv_sec; > int retval = 0; > int real_seconds, real_minutes, cmos_minutes; > unsigned char save_control, save_freq_select; It looks like you now get an invalid 64-bit division in here, you have to change it to either use div_u64_rem() or possibly time64_to_tm() or rtc_time64_to_tm() (the latter requires CONFIG_RTC_LIB). > diff --git a/arch/mips/lasat/ds1603.c b/arch/mips/lasat/ds1603.c > index d75c887..061815e 100644 > --- a/arch/mips/lasat/ds1603.c > +++ b/arch/mips/lasat/ds1603.c > @@ -98,7 +98,7 @@ static void rtc_write_byte(unsigned int byte) > } > } > > -static void rtc_write_word(unsigned long word) > +static void rtc_write_word(time64_t word) > { > int i; > I would say this function should take a 'u32' argument (or keep the unsigned long) to match the name and implementation, but then have a type cast in the caller with a comment about the loss of range and overflow in y2106. > diff --git a/arch/mips/lasat/sysctl.c b/arch/mips/lasat/sysctl.c > index 6f74224..76f7b62 100644 > --- a/arch/mips/lasat/sysctl.c > +++ b/arch/mips/lasat/sysctl.c > @@ -73,8 +73,12 @@ int proc_dolasatrtc(struct ctl_table *table, int write, > if (r) > return r; > > - if (write) > - rtc_mips_set_mmss(rtctmp); > + if (write) { > + ts.tv_sec = rtctmp; > + ts.tv_nsec = 0; > + > + update_persistent_clock64(ts); > + } > ... and probably also a comment here to explain that we can't actually use the full 64-bit range because of HW limits. Arnd