linux-kernel - Re: [PATCH 2/2] net: fec: Reload PTP registers after link-state change

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]

Message-ID: <Zume+IBpZsXTf6+X@lizhi-Precision-Tower-5810>
Date: Tue, 17 Sep 2024 11:23:36 -0400
From: Frank Li <Frank.li@....com>
To: Csókás Bence <csokas.bence@...lan.hu>
Cc: imx@...ts.linux.dev, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Wei Fang <wei.fang@....com>,
	Shenwei Wang <shenwei.wang@....com>,
	Clark Wang <xiaoning.wang@....com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH 2/2] net: fec: Reload PTP registers after link-state
 change

On Tue, Sep 17, 2024 at 09:53:07AM +0200, Csókás Bence wrote:
> Hi!
>
> On 9/16/24 17:05, Frank Li wrote:
> > On Mon, Sep 16, 2024 at 04:19:31PM +0200, Csókás, Bence wrote:
> > > On link-state change, the controller gets reset,
> > > which clears all PTP registers, including PHC time,
> > > calibrated clock correction values etc. For correct
> > > IEEE 1588 operation we need to restore these after
> > > the reset.
> >
> > I am not sure if it necessary. timer will be big offset after reset. ptpd
> > should set_time then do clock frequency adjust, supposed just few ms, ptp
> > time will get resync.
> >
> > of course, restore these value may reduce the resync time.
> >
> > Frank
>
> There's 3 problems with that:
> 1. ATCORR, ATINC and ATPER will not be restored, therefore precision will be
> immediately lost.

Yes, It will be good if you have compare time back to sync with/without
save and restore.

I think ptpd always to make it sync again, just take little bit longer.

> 2. ptpd does NOT set the time, only once, on startup. Currently, on
> link-down, ptpd tries to correct for the missing 54 years by making the PHC
> tick 3% faster (therefore the PPS signal will have a frequency error as
> well), which will never get it there. One work-around is to periodically
> re-start ptpd, but this is obviously sub-optimal.

Supposed it should be ptpd bug. I remember time draft is bigger enough, it
should be set the time again. Maybe ptp change the policy.

For example, if system suspend 1min and resume back, absolute offset will
be 1min offset. ptpd should set the time to catch up offset firstly, then
resync frequency.

> 3. If the PTP server goes away, there's no way to restore the time. Whereas
> if you save and reload it, you can continue, although with degraded
> precision.

This one make sense, you can add to commit message.

>
> Bence
>