Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754564AbbGYDYd (ORCPT ); Fri, 24 Jul 2015 23:24:33 -0400 Received: from mail-ig0-f173.google.com ([209.85.213.173]:36910 "EHLO mail-ig0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753357AbbGYDYc (ORCPT ); Fri, 24 Jul 2015 23:24:32 -0400 MIME-Version: 1.0 In-Reply-To: <1437439549-1012-1-git-send-email-xlpang@126.com> References: <1437439549-1012-1-git-send-email-xlpang@126.com> Date: Fri, 24 Jul 2015 20:24:32 -0700 Message-ID: Subject: Re: [PATCH] mn10300: time: Provide 64-bit persistent clock time From: John Stultz To: Xunlei Pang Cc: lkml , Thomas Gleixner , David Howells , Koichi Yasutake , linux-am33-list@redhat.com, Xunlei Pang , Arnd Bergmann Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1515 Lines: 35 On Mon, Jul 20, 2015 at 5:45 PM, Xunlei Pang wrote: > From: Xunlei Pang > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/