linux-kernel - Re: [GIT PULL] hte: New subsystem for v5.19-rc1

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: <YpzZaJtgXbY0W4Ji@orome>
Date:   Sun, 5 Jun 2022 18:27:20 +0200
From:   Thierry Reding <thierry.reding@...il.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        "D, Lakshmi Sowjanya" <lakshmi.sowjanya.d@...el.com>,
        Dipen Patel <dipenp@...dia.com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        linux-tegra <linux-tegra@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mark Gross <mgross@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "Saha, Tamal" <tamal.saha@...el.com>, bala.senthil@...el.com
Subject: Re: [GIT PULL] hte: New subsystem for v5.19-rc1

On Sat, Jun 04, 2022 at 10:11:17AM +0200, Linus Walleij wrote:
> On Sat, Jun 4, 2022 at 6:38 AM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > On Fri, Jun 3, 2022 at 4:39 AM Thierry Reding <thierry.reding@...il.com> wrote:
> > >
> > > Note that this currently supports only one provider, but there seems to
> > > be enough interest in this functionality and we expect to see more
> > > drivers added once this is merged.
> >
> > So the "one provider" worries me, but the part that really doesn't
> > make me all warm and fuzzy is how this came in at the end of the merge
> > window.
> 
> Another provider did come up, and were requested (by me) to work with
> Dipen on the subsystem in august last year, that was the Intel PMC in the
> Elkhart and Tiger Lake platforms and forward:
> https://patchwork.ozlabs.org/project/linux-gpio/cover/20210824164801.28896-1-lakshmi.sowjanya.d@intel.com/#2766453
> 
> [I added the other Intel people on that submission to CC]
> 
> Intel wanted to put this into the GPIO subsystem and what I saw as maintainer
> was that this is a general problem and general purpose (binary) I/O just isn't
> going to be the only thing they timestamp. Other events will be for IIO and
> hwmon or whatever. They have been
> requested to contribute to Dipens work the recent 9 months ... so... well I
> understand people can get other priorities and stuff.
> 
> Dipen did the right thing and created a separate subsystem that is a provider
> to GPIO and can be a provider to things like IIO as well, which is what
> it needs to be because for things like sensor fusion and industrial control
> systems in general precise timestamps are
> of uttermost importance. And IIO handle a lot of sensors.
> 
> > The DT bindings got the comment "why call it 'hardware timestamp'"
> > when no other case seems sane.
> 
> Intel is talking about "input timestamping", admittedly it is done in hardware
> but the point is to timestamp input I/O events.
> 
> > So the DT bindings got renamed. So now part of the code calls it "hte"
> > (which nobody understands outside of the hte community that is
> > apparently one single device: Tegra) and part of the code calls it
> > "timestamp".
> 
> HTE is "hardware timestamping engine", we have hwmon, hwspinlock,
> hwtracing so maybe hwstamping would be a more natural name then?

Another alternative would be just drivers/timestamp since pretty much
anything in drivers/ is for "hw".

Thierry

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