linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20220308154345.l4mk2oab4u5ydn5r@soft-dev3-1.localhost>
Date:   Tue, 8 Mar 2022 16:43:45 +0100
From:   Horatiu Vultur <horatiu.vultur@...rochip.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     <Divya.Koppera@...rochip.com>, <netdev@...r.kernel.org>,
        <hkallweit1@...il.com>, <linux@...linux.org.uk>,
        <davem@...emloft.net>, <kuba@...nel.org>, <robh+dt@...nel.org>,
        <devicetree@...r.kernel.org>, <richardcochran@...il.com>,
        <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

Hi Andrew,

The 03/08/2022 14:54, Andrew Lunn wrote:
> 
> > > Thanks for the reply, but you did not answer my question:
> > >
> > >   Does this mean the hardware itself cannot tell you it is missing the
> > >   needed hardware?
> > >
> > > Don't you have different IDs in register 2 and 3 for those devices with clock
> > > register and those without?
> > >
> >
> 
> > The purpose of this option is, if both PHY and MAC supports
> > timestamping then always timestamping is done in PHY.  If
> > timestamping need to be done in MAC we need a way to stop PHY
> > timestamping. If this flag is used then timestamping is taken care
> > by MAC.
> 
> This is not a valid use of DT, since this is configuration, not
> describing the hardware. There has been recent extension in the UAPI
> to allow user space to do this configuration. Please look at that
> work.

Ah ... now we have found Richard patch series.
So we will remove this option and once Richard's patch series will be
accepted we will use that.

> 
> > Sorry I answered wrong. Latency values vary depending on the position of PHY in board.
> > We have used this PHY in different hardware's, where latency values differs based on PHY positioning.
> > So we used latency option in DTS file.
> > If you have other ideas or I'm wrong please let me know?
> 
> So this is a function of the track length between the MAC and the PHY?

Nope.
This latency represents the time it takes for the frame to travel from RJ45
module to the timestamping unit inside the PHY. To be more precisely,
the timestamping unit will do the timestamp when it detects the end of
the start of the frame. So it represents the time from when the frame
reaches the RJ45 to when the end of start of the frame reaches the
timestamping unit inside the PHY.

And because each board manufacture could put the same PHY but in
different places, then each of them would have a different latency.
That is the main reason why we put this latencies in the DT and not put
them inside the driver. Because we think each board manufacture will
need to use different values.

Another reason is that we want the board manufacture to determine these
values and not the end users. I have seen that also Richard commenting
on this, saying that the latencies should not be in DT.
Currently I don't know where else they can be. I know that ptp4l has
these option in SW to update the ingress/egress latencies but if someone
else is running another application, what will they do?

> How do you determine these values?

This is a little bit more complicated.
So first you will need a device that you know already that is
calibrated. Then you connect the device that you want to calibrate to
the calibrated one with a known length cable. We presume that there is a
5ns delay per meter of the cable. And then basically we run ptp4l on
each device where the master will be the calibrated one and the slave
will be the device that will be calibrated. When we run ptp4l we can see
mean path delay, and we subtract the delay introduced by the cable(5ns)
and then we take this value and divided by 2. And then
the result is added to the current rx latency and subtracted from tx
latency.
This is how we have calculated the values.

> There is no point having
> configuration values if you don't document how to determine what value
> should be used.

I agree, we should do a better job at this and also explaining what
these values represent. Definitely we will do that in the next patch.

> 
>        Andrew

-- 
/Horatiu