linux-kernel - RE: [PATCH v2 net-next 02/14] dt-bindings: net: add nxp,netc-timer property

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:
 <PAXPR04MB8510333427EE012CF3E2A312885DA@PAXPR04MB8510.eurprd04.prod.outlook.com>
Date: Mon, 21 Jul 2025 06:00:51 +0000
From: Wei Fang <wei.fang@....com>
To: Vladimir Oltean <vladimir.oltean@....com>, Krzysztof Kozlowski
	<krzk@...nel.org>, "richardcochran@...il.com" <richardcochran@...il.com>
CC: "robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
	<krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>, Claudiu
 Manoil <claudiu.manoil@....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>, Frank Li
	<frank.li@....com>, "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 v2 net-next 02/14] dt-bindings: net: add nxp,netc-timer
 property

> > > > > timestamper:	provides control node reference and
> > > > > 			the port channel within the IP core
> > > > >
> > > > > The "timestamper" property lives in a phy node and links a time
> > > > > stamping channel from the controller device to that phy's MII bus.
> > > > >
> > > > > But for NETC, we only need the node parameter, and this property is
> > > > > added to the MAC node.
> > > >
> > > > I think we do not understand each other. I ask if this is the
> > > > timestamper and you explain about arguments of the phandle. The
> > > > arguments are not relevant.
> > > >
> > > > What is this purpose/role/function of the timer device?
> > >
> > > The timer device provides PHC with nanosecond resolution, so the
> > > ptp_netc driver provides interfaces to adjust the PHC, and this PHC
> > > is used by the ENETC device, so that the ENECT can capture the
> > > timestamp of the packets.
> > >
> > > >
> > > > What is the purpose of this new property in the binding here?
> > > >
> > >
> > > This property is to allow the ENETC to find the timer device that is
> > > physically bound to it. so that ENETC can perform PTP synchronization
> > > with other network devices.
> >
> >
> > Looks exactly how existing timestamper property is described.
> >
> > If this is not timestamper then probably someone with better domain
> > knowledge should explain it clearly, so I will understand why it is not
> > timestamper and what is the timestamper property. Then you should think
> > if you need new generic binding for it, IOW, whether this is typical
> > problem you solve here or not, and add such binding if needed.
> >
> > Maybe there is another property describing a time provider in the
> > kernel or dtschema. Please look for it. This all looks like you are
> > implementing typical use case in non-typical, but vendor-like, way.
> >
> > Best regards,
> > Krzysztof
> 
> An MII timestamper and a PTP clock (as integrated in a MAC or a PHY) are
> similar but have some notable differences.
> 
> A timestamper is an external device with a free-running counter, which
> sniffs the MII bus between the MAC and the PHY, and provides timestamps
> when the first octet of a packet hits the wire.
> 
> A PTP clock is also a high precision counter, which can be free-running
> or it can be precisely adjusted. It does not have packet timestamping
> capabilities itself, instead the Ethernet MAC can snapshot this counter
> when it places the first octet of a packet on the MII bus. PTP clocks
> frequently have other auxiliary functions, like emitting external
> signals based on the internal time, or snapshotting external signals.
> 
> The timestamper is not required to have these functions. In fact, I am
> looking at ptp_ines.c, the only non-PHY MII timestamper supported by the
> kernel, and I am noting the fact that it does not call ptp_clock_register()
> at all, presumably because it has no controllable PTP clock to speak of.
> 
> That being said, my understanding is based on analyzing the public code
> available to me, and I do not have practical experience with MII bus
> snooping devices, so if Richard could chime in, it would be great.
> 
> I am also in favor of using the "ptp-timer" phandle to describe the link
> between the MAC and the internal PTP clock that will be snapshot when
> taking packet timestamps. The fman-dtsec.yaml schema also uses it for an
> identical purpose.

Hi Vladimir,

Thanks for the detailed explanation, I think so too, but my previous
explanation was not as convincing and professional as yours, many thanks.

I am not aware of any similar cases before. Thank you for pointing out the
"ptp-timer" property. And I also find the "ptimer-handle" in fsl,fman.yaml,
which has the same purpose as "ptp-timer". Actually, these two properties
are exactly the property I want.  And I think this is exactly what Krzysztof
said, use existing properties instead of adding new properties customized
by the vendor to implement a typical use case.