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  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]
Date:   Thu, 22 Oct 2020 12:01:26 +0300
From:   Vladimir Oltean <>
To:     Richard Cochran <>
Cc:     Christian Eggers <>,
        Florian Fainelli <>,
        Andrew Lunn <>,
        Vivien Didelot <>,
        Jakub Kicinski <>,
        Rob Herring <>,
        Helmut Grohne <>,
        Paul Barker <>,
        Codrin Ciubotariu <>,
        George McCollister <>,
        Marek Vasut <>,
        Tristram Ha <>,
        "David S . Miller" <>,
        Woojung Huh <>,
        Microchip Linux Driver Support <>,,,
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