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

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220312024828.GA15046@hoboy.vegasvil.org>
Date:   Fri, 11 Mar 2022 18:48:28 -0800
From:   Richard Cochran <richardcochran@...il.com>
To:     Woojung.Huh@...rochip.com
Cc:     linux@...linux.org.uk, Horatiu.Vultur@...rochip.com,
        andrew@...n.ch, Divya.Koppera@...rochip.com,
        netdev@...r.kernel.org, hkallweit1@...il.com, davem@...emloft.net,
        kuba@...nel.org, robh+dt@...nel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, UNGLinuxDriver@...rochip.com,
        Madhuri.Sripada@...rochip.com, Manohar.Puri@...rochip.com
Subject: Re: [PATCH net-next 2/3] dt-bindings: net: micrel: Configure latency
 values and timestamping check for LAN8814 phy

On Fri, Mar 11, 2022 at 03:21:58PM +0000, Woojung.Huh@...rochip.com wrote:

> If you are referring to the delayAsymmetry of ptp4l,

No, really, I'm not.

       PTP4l(8)                    System Manager's Manual                   PTP4l(8)

       NAME
           ptp4l - PTP Boundary/Ordinary/Transparent Clock

       ...

       egressLatency
              Specifies  the  difference  in  nanoseconds  between  the actual
              transmission time at the reference plane and the reported trans‐
              mit  time  stamp. This value will be added to egress time stamps
              obtained from the hardware.  The default is 0.

       ingressLatency
              Specifies the difference in nanoseconds between the reported re‐
              ceive  time  stamp  and  the  actual reception time at reference
              plane. This value will be subtracted from  ingress  time  stamps
              obtained from the hardware.  The default is 0.

> So, this latency should (hopefully) be not-much-change in the same board after manufactured. 

Please read the papers on this topic.  I posted links in another reply
in this thread.

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

Yes, you miss the point entirely.  PHY delays are relatively large and
cannot be even measured in some cases.  However, for well behaved
PHYs, the user space stack already covers the configuration.

Thanks,
Richard