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

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

Date:   Thu, 6 Jun 2019 16:40:19 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Richard Cochran <richardcochran@...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 Thu, 6 Jun 2019 at 06:11, Richard Cochran <richardcochran@...il.com> wrote:
>
> 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?
>

Plain and simply because it doesn't work very well.
Even phc2sys from the system clock to the hardware (no timestamps
involved) has trouble staying put (under 1000 ns offset).
And using the hardware-corrected timestamps triggers a lot of clockchecks.

> > 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