Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758590AbbGHMRu (ORCPT ); Wed, 8 Jul 2015 08:17:50 -0400 Received: from skprod3.natinst.com ([130.164.80.24]:44656 "EHLO ni.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754487AbbGHMRs convert rfc822-to-8bit (ORCPT ); Wed, 8 Jul 2015 08:17:48 -0400 Date: Wed, 8 Jul 2015 07:17:37 -0500 From: Josh Cartwright To: Richard Cochran Cc: Christopher Hall , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, john.ronciak@intel.com, john.stultz@linaro.org, tglx@linutronix.de Subject: Re: [PATCH v2 1/1] Added additional callback to ptp_clock_info: Message-ID: <20150708121737.GN25028@jcartwri.amer.corp.natinst.com> References: <1435886088-13890-1-git-send-email-christopher.s.hall@intel.com> <1435886088-13890-2-git-send-email-christopher.s.hall@intel.com> <20150706204458.GE25028@jcartwri.amer.corp.natinst.com> <20150708115434.GA17012@localhost.localdomain> MIME-Version: 1.0 In-Reply-To: <20150708115434.GA17012@localhost.localdomain> User-Agent: Mutt/1.5.23+89 (0255b37be491) (2014-03-12) X-MIMETrack: Itemize by SMTP Server on US-AUS-MGWOut2/AUS/H/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 07/08/2015 07:17:37 AM, Serialize by Router on US-AUS-MGWOut2/AUS/H/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 07/08/2015 07:17:37 AM, Serialize complete at 07/08/2015 07:17:37 AM Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-07-08_05:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1808 Lines: 44 On Wed, Jul 08, 2015 at 01:54:34PM +0200, Richard Cochran wrote: > On Mon, Jul 06, 2015 at 03:44:58PM -0500, Josh Cartwright wrote: > > It's difficult to make too many judgements without seeing how a driver > > might implement this; is there another patchset that shows how a driver > > implements this? > > The interface is certainly clear enough to me. The details of > obtaining a cross time stamp from the hardware will remain hidden > behind the interface in any case. It's unusual to see interfaces added like this without also seeing users at the same time to see how the pieces fit together. Should I have assumed this was a PATCH RFC for just the API? I'm afraid this is the tip of a much larger iceberg. If a device is doing hardware crosstimestamping, what is the hardwares view of this "system clock"? How is it tied into the kernels' timekeeping? How is it ensured that same clock the hardware sees is the kernel's actively selected clocksource? You get this for free in software with getnstimeofday(), by pushing it to hardware, the boundaries of responsibilities are all unclear...without seeing the whole picture. > > > - int rsv[14]; /* Reserved for future use. */ > > > + /* Whether the clock supports precise system-device cross timestamps */ > > > + int precise_timestamping; > > > > Perhaps now is a good time to add an unsigned int 'flags' member instead, > > and start allocating bits. > > Considering the rate of growth for the PHC stuff, I am not worried > about spending a whole 'int' on this. Fair enough! Thanks, Josh -- 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/