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]

Date:   Tue, 23 Mar 2021 10:03:18 +0100
From:   Thierry Reding <thierry.reding@...il.com>
To:     Dipen Patel <dipenp@...dia.com>
Cc:     Richard Cochran <richardcochran@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        Linus Walleij <linus.walleij@...aro.org>,
        Kent Gibson <warthog618@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        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 Mon, Mar 22, 2021 at 01:33:38PM -0700, Dipen Patel wrote:
> Hi Richard,
> 
> Thanks for your input and time. Please see below follow up.
> 
> On 3/20/21 8:38 AM, Richard Cochran wrote:
> > 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
> > 
> GTE gets or rather records the timestamps from the TSC
> (timestamp system coutner) so its not attached to GTE as any
> one can access TSC, so not sure if we really need to implement PHC
> and/or clock_* and friends for the GTE. I believe burden to find correlation
> between various clock domains should be on the clients, consider below
> example.

I agree. My understanding is the the TSC is basically an SoC-wide clock
that can be (and is) used by several hardware blocks. There's an
interface for software to read out the value, but it's part of a block
called TKE (time-keeping engine, if I recall correctly) that implements
various clock sources and watchdog functionality.

As a matter of fact, I recall typing up a driver for that at some point
but I don't recall if I ever sent it out or what became of it. I can't
find it upstream at least.

Anyway, I think given that the GTE doesn't provide that clock itself but
rather just a means of taking a snapshot of that clock and stamping
certain events with that, it makes more sense to provide that clock from
the TKE driver.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)