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

[Wei Fang]

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