On Wed, Jul 08, 2015 at 07:17:37AM -0500, Josh Cartwright wrote:
> 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?
Chris, any idea when we might see a dri
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 t
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
obta
On Thu, Jul 02, 2015 at 06:14:48PM -0700, Christopher Hall wrote:
> * getsynctime64()
Hello Christopher-
A couple comments below.
>
> This takes 2 arguments referring to system and device time
>
> With this callback drivers may provide both system time and device time
> to ensure precise corre
I have three nits to pick...
On Thu, Jul 02, 2015 at 06:14:48PM -0700, Christopher Hall wrote:
> diff --git a/include/linux/ptp_clock_kernel.h
> b/include/linux/ptp_clock_kernel.h
> index b8b7306..344f129 100644
> --- a/include/linux/ptp_clock_kernel.h
> +++ b/include/linux/ptp_clock_kernel.h
> @
* getsynctime64()
This takes 2 arguments referring to system and device time
With this callback drivers may provide both system time and device time
to ensure precise correlation
Modified PTP_SYS_OFFSET ioctl in PTP clock driver to use the above
callback if it's available
Added capability (PTP_
