linux-kernel - RE: [PATCH v3 net-next 05/15] ptp: netc: add PTP_CLK_REQ

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:
 <PAXPR04MB8510EFCF906554968D2380D88835A@PAXPR04MB8510.eurprd04.prod.outlook.com>
Date: Thu, 14 Aug 2025 02:22:47 +0000
From: Wei Fang <wei.fang@....com>
To: Frank Li <frank.li@....com>
CC: "robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
	<krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
	"richardcochran@...il.com" <richardcochran@...il.com>, Claudiu Manoil
	<claudiu.manoil@....com>, Vladimir Oltean <vladimir.oltean@....com>, Clark
 Wang <xiaoning.wang@....com>, "andrew+netdev@...n.ch"
	<andrew+netdev@...n.ch>, "davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org"
	<kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
	"vadim.fedorenko@...ux.dev" <vadim.fedorenko@...ux.dev>,
	"shawnguo@...nel.org" <shawnguo@...nel.org>, "s.hauer@...gutronix.de"
	<s.hauer@...gutronix.de>, "festevam@...il.com" <festevam@...il.com>, "F.S.
 Peng" <fushi.peng@....com>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: RE: [PATCH v3 net-next 05/15] ptp: netc: add PTP_CLK_REQ_PPS support

> On Wed, Aug 13, 2025 at 01:59:01AM +0000, Wei Fang wrote:
> > > On Tue, Aug 12, 2025 at 05:46:24PM +0800, Wei Fang wrote:
> > > > The NETC Timer is capable of generating a PPS interrupt to the host. To
> > > > support this feature, a 64-bit alarm time (which is a integral second
> > > > of PHC in the future) is set to TMR_ALARM, and the period is set to
> > > > TMR_FIPER. The alarm time is compared to the current time on each
> update,
> > > > then the alarm trigger is used as an indication to the TMR_FIPER starts
> > > > down counting. After the period has passed, the PPS event is generated.
> > > >
> > > > According to the NETC block guide, the Timer has three FIPERs, any of
> > > > which can be used to generate the PPS events, but in the current
> > > > implementation, we only need one of them to implement the PPS feature,
> > > > so FIPER 0 is used as the default PPS generator. Also, the Timer has
> > > > 2 ALARMs, currently, ALARM 0 is used as the default time comparator.
> > > >
> > > > However, if there is a time drift when PPS is enabled, the PPS event will
> > > > not be generated at an integral second of PHC. The suggested steps from
> > > > IP team if time drift happens:
> > >
> > > according to patch, "drift" means timer adjust period?
> >
> > No only adjust period, but also including adjust time.
> 
> I think 'adjust period and time' is more accurate then drift.  drift always
> happen. The problem should happen only at adjust.
> 
> >
> > > netc_timer_adjust_period()
> > >
> > > generally, netc_timer_adjust_period() happen 4 times every second, does
> > > disable/re-enable impact pps accurate?
> >
> > PPS needs to be re-enabled only when the integer part of the period changes.
> > In this case, re-enabling PPS will result in a loss of PPS signal for 1 ~ 2 seconds.
> > In most cases, only the fractional part of the period is adjusted, so there is no
> > need to re-enable PPS.
> 
> Lost 1-2 second should be okay when adjust time, which only happen at
> beginning of sync.
> 
> Does software enable/disable impact PPS accurate? For example:
> 
> suppose PPS plus at 10000ns position.
> 
> enable/disable software take 112ns, does PPS plus at 10112ns Or still at
> 10000ns position.
> 

The purpose is to make the PPS signal always be generated at an integral
second of PHC. Below are the results without and with PPS re-enabled
when adjusting the integer part of the period.

Without PPS re-enabled:

#before adjustment
event index 0 at 39.000000017
event index 0 at 40.000000017

#adjust period
./testptp -d /dev/ptp0 -f -1000000

#after adjustment, the generation time of the PPS signal gradually drifts,
and the deviation from the integer second becomes larger and larger.
event index 0 at 41.000000017
event index 0 at 42.000000017
[...]
event index 0 at 128.999999931
event index 0 at 129.999999928

With PPS re-enabled:

#before adjustment
event index 0 at 86.000000017
event index 0 at 87.000000017

./testptp -d /dev/ptp0 -f -1000000

#after adjustment, a PPS signal will be lost at 88 second, but the generation
time of the PPS signal does not drift.
event index 0 at 89.000000017
event index 0 at 90.000000017
[...]
event index 0 at 161.000000017
event index 0 at 162.000000017