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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 14 May 2020 17:09:01 +0200
From:   Olivier Dautricourt <olivier.dautricourt@...lia.com>
To:     Richard Cochran <richardcochran@...il.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

The 05/14/2020 06:53, Richard Cochran wrote:
> 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...
  
  I have not, but i'll look deeper in the way this use case is handled
  in this series..

> 
> > 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.

  My issue is that the default behavior of the stmmac driver is to
  set the mac into fine mode which implies to continuously do frequency
  adjustment, So if i'm not mistaken using the nullf servo will not address
  that issue even if we are not doing explicit clock_adjtime syscalls.
  
  Patches 2/3 and 3/3 are reponsible for preventing this.
> 
> Thanks,
> Richard
> 
> ATTENTION: This email came from an external source.
> Do not open attachments or click on links from unknown senders or unexpected emails.

Regards,

-- 
Olivier Dautricourt