netdev - Re: GTE - The hardware timestamping engine

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: <20210320153855.GA29456@hoboy.vegasvil.org>
Date:   Sat, 20 Mar 2021 08:38:55 -0700
From:   Richard Cochran <richardcochran@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Dipen Patel <dipenp@...dia.com>,
        Kent Gibson <warthog618@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "thierry.reding@...il.com" <thierry.reding@...il.com>,
        Jon Hunter <jonathanh@...dia.com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-tegra <linux-tegra@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Networking <netdev@...r.kernel.org>
Subject: Re: GTE - The hardware timestamping engine

On Sat, Mar 20, 2021 at 01:44:20PM +0100, Arnd Bergmann wrote:
> Adding Richard Cochran as well, for drivers/ptp/, he may be able to
> identify whether this should be integrated into that framework in some
> form.

I'm not familiar with the GTE, but it sounds like it is a (free
running?) clock with time stamping inputs.  If so, then it could
expose a PHC.  That gets you functionality:

- clock_gettime() and friends
- comparison ioctl between GTE clock and CLOCK_REALTIME
- time stamping channels with programmable input selection

The mentioned applications (robotics and autonomous vehicle, so near
and dear to my heart) surely already use the PHC API for dealing with
network and system time sources, and so exposing the GTE as a PHC
means that user space programs will have a consistent API.

[ The only drawback I can see is the naming of the C language
  identifiers in include/uapi/linux/ptp_clock.h.  If that bothers
  people, then these can be changed to something more generic while
  keeping compatibility aliases. ]

Thanks,
Richard