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]

Message-ID: <CACRpkdaTaDNB12vkmUVdmk0yBH-YW07RfcDO97q7d+ppLHj_iQ@mail.gmail.com>
Date:   Sat, 3 Dec 2022 10:49:50 +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>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: Intel timed i/o driver in HTE

On Fri, Dec 2, 2022 at 4:00 AM N, Pandith <pandith.n@...el.com> wrote:

> > 1. Does timed io only meant for GPIO or other signals? if other signals, what
> > type of signals?
> This could be time sync signals or periodic/single pulse input for timestamp support
(...)
> b. char device creation for timestamping hardware. Something like /dev/hteX

No way this goes to userspace if the usecase is synchronizing GPS time.

It should be in the kernel, where the timebase of the system is.

We already created drivers/gnss because power, clock etc management
need to be close to the hardware, in the kernel. Don't try to push this
up to userspace, group it with the rest of the kernel GPS handling.

If your GPS vendor doesn't want the kernel to talk directly to the GPS,
bad luck, because the kernel definitely should in this case.  The kernel
has the best time source and the shortest access path to it, so there
you go.

The GPS vendors have already created enough of a mess by not having
open documentation for their hardware, if this is an incentive for them to
be more open if they want proper time sync that is *good*.

Yours,
Linus Walleij