linux-kernel - Re: Intel timed i/o driver in HTE

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:   Wed, 30 Nov 2022 10:00:49 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     "N, Pandith" <pandith.n@...el.com>, Johan Hovold <johan@...nel.org>
Cc:     Dipen Patel <dipenp@...dia.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Hall, Christopher S" <christopher.s.hall@...el.com>,
        "Gross, Mark" <mark.gross@...el.com>,
        "Sangannavar, Mallikarjunappa" 
        <mallikarjunappa.sangannavar@...el.com>,
        "D, Lakshmi Sowjanya" <lakshmi.sowjanya.d@...el.com>,
        "T R, Thejesh Reddy" <thejesh.reddy.t.r@...el.com>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "timestamp@...ts.linux.dev" <timestamp@...ts.linux.dev>
Subject: Re: Intel timed i/o driver in HTE

On Tue, Nov 29, 2022 at 7:10 PM N, Pandith <pandith.n@...el.com> wrote:

> Intel  timed i/o is mainly intended for couple of functionalities.
> 1. Input event capture with timestamping

I understand this part, and it is handled by the HTE subsystem.

> 2. Generate single shot or periodic pulse train
(...)
> c. Most importantly, precise time synchronization between devices/sub-systems
> Ex : Share precise time from a GPS receiver to the network or
>        Synchronize processor clock with external signal.

So I think this is the actual use case of the output mode. The
pulse train output by HTE is to share precise time to GPS receivers.

So what about putting that part into drivers/gnss?
GNSS Global Navigation Satellite Subsystem like GPS etc

If this is the only usecase, that is where it should go, along
with the serial or whatever transport driver is used with the
GPS. I don't think this is a generic functionality (such as
GPIO) at all, but rather a very application-specific use case
which will only be used for GPS time synchronization.

If the timed output has other use cases - and I mean HAVE
other use cases, not COULD HAVE other use cases - then
we can discuss generalizations. There is no point of designing
upfront abstractions that never get used.

Yours,
Linus Walleij