linux-kernel - Re: [PATCH v3 net-next 00/17] PTP support for the SJA1105 DSA driver

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: <20190606031135.6lyydjb6hqfeuzt3@localhost>
Date:   Wed, 5 Jun 2019 20:11:35 -0700
From:   Richard Cochran <richardcochran@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Stephen Boyd <sboyd@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v3 net-next 00/17] PTP support for the SJA1105 DSA driver

On Wed, Jun 05, 2019 at 09:08:54PM +0300, Vladimir Oltean wrote:
> Currently I'm using a cyclecounter, but I *will* need actual PHC
> manipulations for the time-based shaping and policing features that
> the switch has in hardware.

Okay.

> On the other hand I get much tighter sync
> offset using the free-running counter than with hardware-corrected
> timestamps.

Why?  The time stamps come from the very same counter, don't they?

> So as far as I see it, I'll need to have two sets of
> operations.

I doubt very much that this will work well.

> How should I design such a dual-PHC device driver? Just register two
> separate clocks, one for the timestamping counter, the other for the
> scheduling/policing PTP clock, and have phc2sys keep them in sync
> externally to the driver?

But how would phc2sys do this?  By comparing clock_gettime() values?
That would surely introduce unnecessary time error.

> Or implement the hardware corrections
> alongside the timecounter ones, and expose a single PHC (and for
> clock_gettime, just pick one of the time sources)?

I would implement the hardware clock and drop the timecounter
altogether.

HTH,
Richard