netdev - Re: [PATCH] ptp: Add PTP_CLOCK_EXTTSUSR internal ptp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 30 Jun 2021 07:42:57 -0700
From:   Richard Cochran <richardcochran@...il.com>
To:     Jonathan Lemon <jonathan.lemon@...il.com>
Cc:     netdev@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCH] ptp: Add PTP_CLOCK_EXTTSUSR internal ptp_event

On Tue, Jun 29, 2021 at 08:50:31PM -0700, Jonathan Lemon wrote:
> The PHC should be sync'd to the PPS coming from the GPS signal.
> However, the GPS may be in holdover, so the actual counter comes
> from an atomic oscillator.  As the oscillator may be ever so 
> slightly out of sync with the GPS (or drifts with temperature),
> so we need to measure the phase difference between the two and
> steer the oscillator slightly.
> 
> The phase comparision between the two signals is done in HW 
> with a phasemeter, for precise comparisons.  The actual phase
> steering/adjustment is done through adjphase().

So you don't need the time stamp itself, just the phase offset, right?

> What's missing is the ability to report the phase difference
> to user space so the adjustment can be performed.

So let's create an interface for that reporting.

> Since these events are channel specific, I don't see why
> this is problematic.  The code blocks in question from my
> upcoming patch (dependent on this) is:

The long standing policy is not to add new features that don't have
users.  It would certainly help me in review if I could see the entire
patch series.  Also, I wonder what the user space code looks like.

> I'm not seeing why this is controversial.

It is about getting the right interface.  The external time stamp
interface is generic and all-purpose, and so I question whether your
extension makes sense.

I guess from what you have explained so far that the:

- GPS produces a pulse on the full second.
- That pulse is time stamped in the PHC.
- The HW calculates the difference between the full second and the
  captured time.
- User space steers the PHC based on the difference.

If this is so, why not simply use the time stamp itself?  Or if the
extra number is a correction to the time stamp, why not apply the
correction to the time stamp?

Thanks,
Richard