Received: by 10.192.165.148 with SMTP id m20csp2794399imm; Mon, 7 May 2018 00:59:24 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqUwypL35qhJ0mAD6di4HoTL6h8A3oPQAQkTcYsbvKW9DGmQKTfYQAgrieYnyru+QSLslqF X-Received: by 10.98.215.81 with SMTP id v17mr35819573pfl.39.1525679964509; Mon, 07 May 2018 00:59:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525679964; cv=none; d=google.com; s=arc-20160816; b=H05kw6aRVi1zc8Bp9YAgH+SQI9QyCEjKinGAJv9Jl3aLJwOuvMZQ3L+Otfdml8tWiE IXkYGE2Qlg9sI+crotaiz4iR2nkro5Tkf6EFXuDOOp3JpMc3/UI7LYvLRarGGCwnFKEg pbPXs+kEGAguwKDgk0rd3LMmeNCJHAwYnhrp8v0oEto/fvos0vCrnRO+sJKYAR5SVDjl Kg34J0+5ab2pjbuT3c+1ap0qniOK07hf4nF4R/zTmFNdYJyKh/VjDgZzAHS/zfq6YcpI Rp/wRX4akbuczigR9ipMfBqvsBztOl8v66PU0TZdqvyh6OQKJ6fHL4NheIqDCyRhGiU4 ZE1w== 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=/VzuEq7u+284TbkrLjTHvh+qrVteUcrV4bO1LSCVkAc=; b=GhB3o47aMCJoDGUJJvsGK4g4j/XXHvtYy4V8jY6kcLSPsQl7HuGzgOvEgyEXr1PrE+ QDUZj2hr1oe8tfreP202Q+hz+Jr6d6ZbTr7U/luH2A2bzrS2+/4AGgPrj2xLFjibACnq PqWwJcnRHBvi0HzpMPOcSJZEc7l01zsDbkePUR+JeM6ROYXzGAAMCcpRqSDoPVZuttr7 XGXOi1fN4UCJ+f2D0Yz6DBIXjRIZMKpx79eP+IzT0S1Phvhm04oHbgYGsNpnzVnKjYtx 5XavyfUPJmwf7u4oQPxn0Da60cNie4K6f+ib3H5HR8ZV82VJQecnytWIbi39cC4fGuoj CrEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=kzenOqN4; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f14-v6si17881222pgu.612.2018.05.07.00.59.09; Mon, 07 May 2018 00:59:24 -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=pass header.i=@linaro.org header.s=google header.b=kzenOqN4; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751952AbeEGH5t (ORCPT + 99 others); Mon, 7 May 2018 03:57:49 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:36166 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751042AbeEGH5s (ORCPT ); Mon, 7 May 2018 03:57:48 -0400 Received: by mail-oi0-f65.google.com with SMTP id v2-v6so24323334oif.3 for ; Mon, 07 May 2018 00:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/VzuEq7u+284TbkrLjTHvh+qrVteUcrV4bO1LSCVkAc=; b=kzenOqN4GFagoPS2ESPeEaKhAuUmeouhUK0zGBOf0vyNSe0yByDF+d9P3fWGiJKRNv zNnv329X8SUu57eJcJwwSt5EtPOBs5w/s1dpDx6FdLyFmKmcxidPAx0BxF/N0U8LMMoD OrjbPeOQhwIZ3aQMZ4hrcNuhg4jT+9yGWxIK0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/VzuEq7u+284TbkrLjTHvh+qrVteUcrV4bO1LSCVkAc=; b=oCEWJgLZ2tJB6/6R8rgaPouIkaHdqIWuBwvYiWzg32yObdcYhUXzTm/JB++A1WgS2l +DkMCNOwLhZDJCdYrPYS6q1s8mRXUx4AYF5Ebq0XoipUFDq0abw6LmYBRYksQSQUeN6a BGMoLJILhfQiTCb7B40A97KyYsZ2+K51LLJYykPut2/5RuUB0V3ke+y9Tz0pO6JUYcIz bTvzkkiJ+BuS+lnKf6Z92NRLoXRNxMEBZG27wQie0ceXIQg8lWfTc1uvKUVcOYMTbT8z KLyQDsWGiZA0b0jbruivhNe4Rfe4wXwqg1V7trJ9p6+Ow/i/afKAhDzm0nFiSBBM8xXR 36LQ== X-Gm-Message-State: ALQs6tAPQHHx5YX8aUwww/ExQQZsWOX700SKmdZ9R7LK96u9QNbobjCY R2gD6NOwBOrdzryX/o0hczkWdsXYjxloijAc2hZSJg== X-Received: by 2002:aca:accf:: with SMTP id v198-v6mr22903246oie.320.1525679867728; Mon, 07 May 2018 00:57:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2d77:0:0:0:0:0 with HTTP; Mon, 7 May 2018 00:57:47 -0700 (PDT) In-Reply-To: References: <2d0bcca30f61036e413ba01c686ce6506f187462.1525417306.git.baolin.wang@linaro.org> From: Baolin Wang Date: Mon, 7 May 2018 15:57:47 +0800 Message-ID: Subject: Re: [PATCH v2 2/2] MIPS: Convert update_persistent_clock() to update_persistent_clock64() To: Arnd Bergmann 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 6 May 2018 at 11:04, Arnd Bergmann wrote: > 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). I will use div_u64_rem() to calculate real_seconds and real_minutes. > >> 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. OK. > >> 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. > OK. Thanks for your comments. -- Baolin.wang Best Regards