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
| ||
|
Date: Thu, 22 Oct 2020 12:01:26 +0300 From: Vladimir Oltean <olteanv@...il.com> To: Richard Cochran <richardcochran@...il.com> Cc: Christian Eggers <ceggers@...i.de>, Florian Fainelli <f.fainelli@...il.com>, Andrew Lunn <andrew@...n.ch>, Vivien Didelot <vivien.didelot@...il.com>, Jakub Kicinski <kuba@...nel.org>, Rob Herring <robh+dt@...nel.org>, Helmut Grohne <helmut.grohne@...enta.de>, Paul Barker <pbarker@...sulko.com>, Codrin Ciubotariu <codrin.ciubotariu@...rochip.com>, George McCollister <george.mccollister@...il.com>, Marek Vasut <marex@...x.de>, Tristram Ha <Tristram.Ha@...rochip.com>, "David S . Miller" <davem@...emloft.net>, Woojung Huh <woojung.huh@...rochip.com>, Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>, netdev@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [RFC PATCH net-next 7/9] net: dsa: microchip: ksz9477: add hardware time stamping support On Wed, Oct 21, 2020 at 08:02:17PM -0700, Richard Cochran wrote: > On Thu, Oct 22, 2020 at 02:39:35AM +0300, Vladimir Oltean wrote: > > So how _does_ that work for TI PHYTER? > > > > As far as we understand, the PHYTER appears to autonomously mangle PTP packets > > in the following way: > > - subtracting t2 on RX from the correctionField of the Pdelay_Req > > - adding t3 on TX to the correctionField of the Pdelay_Resp > > The Phyter does not support peer-to-peer one step. Ok, that's my mistake for not double-checking, sorry. > The only driver that implements it is ptp_ines.c. > > And *that* driver/HW implements it correctly. Is there documentation available for this timestamping block? I might be missing some data, as the kernel driver is fairly pass-through for the TX timestamping of the Pdelay_Resp, so the hardware might just 'do the right thing'. I believe the answer lies within the timestamper's per-port RX FIFO. Just guessing here, but I suspect that the RX FIFO doesn't get cleared immediately after the host queries it, and the hardware caches the last 100 events from the pool and uses the RX timestamps of Pdelay_Req as t2 in the process of updating the correctionField of Pdelay_Resp on TX. Would that be correct?
Powered by blists - more mailing lists