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  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:   Thu, 14 May 2020 06:53:25 -0700
From:   Richard Cochran <>
To:     Olivier Dautricourt <>
Cc:     Giuseppe Cavallaro <>,
        Alexandre Torgue <>,
        Jose Abreu <>,
        "David S . Miller" <>,
Subject: Re: [PATCH 0/3] Patch series for a PTP Grandmaster use case using
 stmmac/gmac3 ptp clock

On Thu, May 14, 2020 at 12:28:05PM +0200, Olivier Dautricourt wrote:
> This patch series covers a use case where an embedded system is
> disciplining an internal clock to a GNSS signal, which provides a
> stable frequency, and wants to act as a PTP Grandmaster by disciplining
> a ptp clock to this internal clock.

Have you seen the new GM patch series on the linuxptp-devel mailing
list?  You may find it interesting...
> In our setup a 10Mhz oscillator is frequency adjusted so that a derived
> pps from that oscillator is in phase with the pps generated by 
> a gnss receiver.
> An other derived clock from the same disciplined oscillator is used as
> ptp_clock for the ethernet mac.
> The internal pps of the system is forwarded to one of the auxiliary inputs
> of the MAC.
> Initially the mac time registers are considered random.
> We want the mac nanosecond field to be 0 on the auxiliary pps input edge.
> PATCH 1/3: 
> 	The stmmac gmac3 version used in the setup is patched to retrieve a
> 	timestamp at the rising edge of the aux input and to forward
> 	it to userspace.
> * What matters here is that we get the subsecond offset between the aux 
> edge and the edge of the PHC's pps. *
> PATCH 2,3/3:
> 	We want the ptp clock to be in time with our aux pps input.
> 	Since the ptp clock is derived from the system oscillator, we
> 	don't want to do frequency adjustements.
> 	The stmmac driver is patched to allow to set the coarse correction
> 	mode which avoid to adjust the frequency of the mac continuously
> 	(the default behavior), but instead, have just one
> 	time adjustment.

You can use the new ts2phc program (in the linuxptp-devel patch
series, soon to be merged) by configuring it to use the nullf servo.


Powered by blists - more mailing lists