From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752260AbbCUBQy (ORCPT ); Fri, 20 Mar 2015 21:16:54 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:55022 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751632AbbCUBQv (ORCPT ); Fri, 20 Mar 2015 21:16:51 -0400 From: Arnd Bergmann Organization: Linaro Ltd To: Richard Cochran Subject: Re: [PATCH 2/4] ptp/clcok:Introduce the setktime/getktime interfaces with "ktime_t" type Date: Sat, 21 Mar 2015 02:16:41 +0100 User-Agent: KMail/1.12.2 (Linux/3.8.0-35-generic; KDE/4.3.2; x86_64; ; ) Cc: Baolin Wang , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, John Stultz , tglx@linutronix.de References: <1426743909-24335-1-git-send-email-baolin.wang@linaro.org> <201503201443.42672.arnd@linaro.org> <20150320164951.GA25334@localhost.localdomain> In-Reply-To: <20150320164951.GA25334@localhost.localdomain> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201503210216.41497.arnd@linaro.org> X-Provags-ID: V03:K0:KgRy7OThW3UvDokSbJx780+cKbZbggYgYkr/IP5K4pv+ZfwTN3x W0k1/KMd2mLPmdorDxe8+PYPXp/TZb4qQqt8f4yDRgQvl3Nrhc2xy51zJjtBf1pdOgecXIp mybgluAjqn69ld26BmFPQ2KStveO/XnHL0GpgOPDE9iMGqD96wMZaI7piE9Ijlps4zomMc1 Zz/kW9UvelLYyTWYREiOQ== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 20 March 2015, Richard Cochran wrote: > Instead of changing to ktime_t, just use timespec64 instead. That > way, each change will be a couple of lines per file. This was the first idea, but it seems a bit silly when all the drivers use a 64-bit nanosecond value just like ktime_t. While both of the current users require a timespec at the moment, it's possible that there would one day be a third user that actually can make sense of a ktime_t, and then we'd avoid the expensive back-and-forth conversion. For now, using ktime_t in the interface merely simplifies the drivers by moving the conversion into the subsystem, but it is not any more or less efficient than the previous method. > > I do agree however that we should merge the entire series at once so > > we end up with a reasonable state afterwards, and we only need the conditional > > in order to have a bisectable git history. > > It is still bisectable with one or two patches. Of course, but it would be rather bad style. Arnd