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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 14 May 2020 17:37:06 -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 05:09:01PM +0200, Olivier Dautricourt wrote: > 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. Why not use the external time stamps from your GPS to do one of the following? A) Feed them into a user space PI controller and do frequency correction, or B) Feed the offsets into the hardware PLL (if that is present) using the new PHC ADJ_OFFSET support (found in net-next). I don't see a need for changing any kernel interfaces at all. If you think there is such a need, then you will have to make some kind of argument or justification for it. BTW, support for B has been implemented in linuxptp, and the patches will appear soon. We can also add it into the ts2phc program if you like. Thanks, Richard
Powered by blists - more mailing lists