RE: [PATCH net-next 2/3] dt-bindings: net: micrel: Configure latency values and timestamping check for LAN8814 phy

[Woojung.Huh]

Hi Richard,

Not sure that it is good idea to reply on not-the-latest thread.

> -----Original Message-----
> From: Richard Cochran <richardcochran@xxxxxxxxx>
> Sent: Wednesday, March 9, 2022 2:53 PM
> To: Russell King (Oracle) <linux@xxxxxxxxxxxxxxx>
> Cc: Horatiu Vultur - M31836 <Horatiu.Vultur@xxxxxxxxxxxxx>; Andrew Lunn
> <andrew@xxxxxxx>; Divya Koppera - I30481
> <Divya.Koppera@xxxxxxxxxxxxx>; netdev@xxxxxxxxxxxxxxx;
> hkallweit1@xxxxxxxxx; davem@xxxxxxxxxxxxx; kuba@xxxxxxxxxx;
> robh+dt@xxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; UNGLinuxDriver
> <UNGLinuxDriver@xxxxxxxxxxxxx>; Madhuri Sripada - I34878
> <Madhuri.Sripada@xxxxxxxxxxxxx>; Manohar Puri - I30488
> <Manohar.Puri@xxxxxxxxxxxxx>
> Subject: Re: [PATCH net-next 2/3] dt-bindings: net: micrel: Configure latency
> values and timestamping check for LAN8814 phy
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> On Wed, Mar 09, 2022 at 02:55:49PM +0000, Russell King (Oracle) wrote:
> 
> > I think we understand this, and compensating for the delay in the PHY
> > is quite reasonable, which surely will be a fixed amount irrespective
> > of the board.
> 
> The PHY delays are not fixed.  They can be variable, even packet to packet.
> 
> https://www.researchgate.net/publication/260434179_Measurement_of_e
> gress_and_ingress_delays_of_PTP_clocks
> 
> https://www.researchgate.net/publication/265731050_Experimental_verific
> ation_of_the_egress_and_ingress_latency_correction_in_PTP_clocks
> 
> Some PHYs are well behaved.  Some are not.
> 
> In any case, the linuxptp user space stack supports the standardized
> method of correcting a system's delay asymmetry.  IMO it makes no
> sense to even try to let kernel device drivers correct these delays.
> Driver authors will get it wrong, and indeed they have already tried
> and failed.  And when the magic numbers change from one kernel release
> to another, it only makes the end user's job harder, because they will
> have to update their scripts to correct the bogus numbers.
> 

If you are referring to the delayAsymmetry of ptp4l, I think that is different from this latency value.
delayAsymmetry of ptp4l says "The time difference in nanoseconds of the transmit and receive  paths. 
This value should be positive when the master-to-slave propagation time is longer and negative
when the slave-to-master time is longer. The default is 0 nanoseconds."
In my understanding, master-to-slave uses reference timestamp which is defined in IEEE specs.
   <egressTimestamp> = <egressProvidedTimestamp> + <egressLatency>
   <ingressTimestamp> = <ingressProvidedTimestamp> - <ingressLatency>

These latency is egreeLatency or ingressLatency to get accurate timestamp at reference point from 
timestamp of clock in MAC or PHY.
So, this latency should (hopefully) be not-much-change in the same board after manufactured. 
But, value can be different from design to design and port to port if some path (PHY to RJ45) is longer than others.

This doesn't cover any latency from cable length and/or asymmetry which may come from RJ45-to-RJ45.
But, delayAsymmetry may care cable type/length in application point of view.

Of cause, all values may be small enough to ignore though.
Do I miss something here?

Thanks.
Woojung