netdev - Re: [PATCH 0/3] Patch series for a PTP Grandmaster use case using stmmac/gmac3 ptp clock

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:   Thu, 14 May 2020 06:53:25 -0700
From:   Richard Cochran <richardcochran@...il.com>
To:     Olivier Dautricourt <olivier.dautricourt@...lia.com>
Cc:     Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Jose Abreu <joabreu@...opsys.com>,
        "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org
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.

Thanks,
Richard