netdev - Re: [PATCH net-next v6 4/7] net: dsa: hellcreek: Add support for hardware timestamping

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: <20201008150951.elxob2yaw2tirkig@skbuf>
Date:   Thu, 8 Oct 2020 18:09:51 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Kamil Alkhouri <kamil.alkhouri@...offenburg.de>
Cc:     Kurt Kanzenbach <kurt@...utronix.de>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Richard Cochran <richardcochran@...il.com>,
        ilias.apalodimas@...aro.org
Subject: Re: [PATCH net-next v6 4/7] net: dsa: hellcreek: Add support for
 hardware timestamping

Hi Kamil,

On Thu, Oct 08, 2020 at 02:55:57PM +0200, Kamil Alkhouri wrote:
> Hello dears,
> 
> On Thu, 2020-10-08 at 12:01 +0200, Kurt Kanzenbach wrote:
> > On Thu Oct 08 2020, Vladimir Oltean wrote:
> > > On Thu, Oct 08, 2020 at 10:34:11AM +0200, Kurt Kanzenbach wrote:
> > > > On Wed Oct 07 2020, Vladimir Oltean wrote:
> > > > > On Wed, Oct 07, 2020 at 12:39:49PM +0200, Kurt Kanzenbach
> > > > > wrote:
> > > > > > For instance the hellcreek switch has actually three ptp
> > > > > > hardware
> > > > > > clocks and the time stamping can be configured to use either
> > > > > > one of
> > > > > > them.
> > > > > 
> > > > > The sja1105 also has a corrected and an uncorrected PTP clock
> > > > > that can
> > > > > take timestamps. Initially I had thought I'd be going to spend
> > > > > some time
> > > > > figuring out multi-PHC support, but now I don't see any
> > > > > practical reason
> > > > > to use the uncorrected PHC for anything.
> > > > 
> > > > Just out of curiosity: How do you implement 802.1AS then? My
> > > > understanding is that the free-running clock has to be used for
> > > > the
> > > 
> > > Has to be? I couldn't find that wording in IEEE 802.1AS-2011.
> > 
> > It doesn't has to be, it *should* be. That's at least the outcome we
> > had
> > after lots of discussions. Actually Kamil (on Cc) is the expert on
> > this
> > topic.
> 
> According to 802.1AS-2011 (10.1.1): "The LocalClock entity is a free-
> running clock (see 3.3) that provides a common time to the time-aware
> system, relative to an arbitrary epoch.", "... All timestamps are taken
> relative to the LocalClock entity". The same statement holds true for
> 802.1AS-2020 (10.1.2.1).

Nice having you part of the discussion.

IEEE 802.1AS-rev draft 8.0, clause F.3 PTP options:

	The physical adjustment of the frequency of the LocalClock
	entity (i.e., physical syntonization) is allowed but not
	required.

In fact, even if that wasn't explicitly written, I am having a hard time
understanding how the "B.1.1 Frequency accuracy" requirement for the
LocalClock could be satisfied as long as it is kept free-running.
Otherwise said, what should I do as a system designer if the
LocalClock's frequency is not within +/- 100 ppm offset to the TAI
frequency, and I'm not allowed to correct it.

By the way, how would you see the split between an unsynchronized and a
synchronized PHC be implemented in the Linux kernel?

Thanks,
-Vladimir