From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751424AbdH1POE (ORCPT ); Mon, 28 Aug 2017 11:14:04 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:48581 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751318AbdH1POD (ORCPT ); Mon, 28 Aug 2017 11:14:03 -0400 Date: Mon, 28 Aug 2017 17:13:58 +0200 (CEST) From: Thomas Gleixner To: Pasha Tatashin cc: x86@kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, hpa@zytor.com, douly.fnst@cn.fujitsu.com Subject: Re: [PATCH v5 1/2] sched/clock: interface to allow timestamps early in boot In-Reply-To: <2d5087a2-2aca-aaba-4608-112facbd3208@oracle.com> Message-ID: References: <1503520884-99253-1-git-send-email-pasha.tatashin@oracle.com> <1503520884-99253-2-git-send-email-pasha.tatashin@oracle.com> <2d5087a2-2aca-aaba-4608-112facbd3208@oracle.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 28 Aug 2017, Pasha Tatashin wrote: > This makes sense. Changing order in timekeeping_init(void) should take care of > this: > > Change to: > > void __init timekeeping_init(void) > { > /* > * We must determine boot timestamp before getting current > * persistent clock value, because implementation of > * read_boot_clock64() might also call the persistent > * clock, and a leap second may occur. > */ > > read_boot_clock64(&boot); > ... > read_persistent_clock64(&now); No. That's the same crap just the other way round. s390 can do that, because the boot timestamp is correlated with the persistent clock. Your's not so much. Thanks, tglx