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@linux-foundation.org> wrote:
> > On Fri, Jun 3, 2022 at 4:39 AM Thierry Reding <thierry.reding@gmail.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