From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752191AbbCTNny (ORCPT ); Fri, 20 Mar 2015 09:43:54 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:49823 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751911AbbCTNnv (ORCPT ); Fri, 20 Mar 2015 09:43: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: Fri, 20 Mar 2015 14:43:42 +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> <20150320062603.GC4417@localhost.localdomain> In-Reply-To: <20150320062603.GC4417@localhost.localdomain> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201503201443.42672.arnd@linaro.org> X-Provags-ID: V03:K0:j+wJWNXa5wz6RZRGrKkPDencjRzqFA6wXwR/eId6YFH+0Ixs+za unzWSQ+9czOz56BYKaN/QCP+KNtTFAF9KudYacRPsV5HcEU8611FhqA6yD5f80KO21BFJ0j YelP13zd//Rk+DIACycxaiwFkARDsuJHPToiRELawVp9Vgs+PlUCRB7LTZAxB9czFRpposn eu2mpDDHJ9YgTCwcHbASg== 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: > On Fri, Mar 20, 2015 at 09:54:05AM +0800, Baolin Wang wrote: > > Next patch series will contain all of the drivers which need to be changed. > > But i think the conditional in ptp_clock.c can still in there. > > Why? > > > Because our plan is once all the drivers are converted, i will remove the > > conditional, along with the original function pointer. > > Is that OK? Thanks! > > I want to avoid a patch series that introduces something, only to > remove it later on. Sometimes you have to do that way for a complex > transformation, but this case is rather simple. > > You can change the gettime signature in one patch, and the settime in > a second patch. We normally try to avoid doing those global API changes across many drivers that are maintained by different people. Introducing the new API first is the easiest way to get the per-driver patches reviewed individually by the respective maintainers. Doing gettime separately from settime would be rather silly here, so trying to avoid the conditional would mean doing a single large patch across all drivers. 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. Arnd