linux-kernel - 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:08:00 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Dipen Patel <dipenp@...dia.com>
Cc:     Kent Gibson <warthog618@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "thierry.reding@...il.com" <thierry.reding@...il.com>,
        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>,
        Arnd Bergmann <arnd@...db.de>,
        Richard Cochran <richardcochran@...il.com>
Subject: Re: GTE - The hardware timestamping engine

On Mon, Mar 22, 2021 at 9:17 PM Dipen Patel <dipenp@...dia.com> wrote:

> My follow-up concerns on both Linus's and Kent's feedback:
>
> 1.  Please correct me if I am wrong, lineevent in the gpiolib* is only
>     serves the userspace clients.
> 1.a What about kernel drivers wanting to use this feature for monitoring its
>     GPIO lines, see gyroscope example somewhere below. In that regards,
>     lineevent implementation is not sufficient.
> 1.b Are you also implying to extend lineevent implementation to kernel
>     drivers?

I was talking about lineevent because you mentioned things like
motors and robotics, and those things are traditionally not run in
kernelspace because they are not generic hardware that fit in the
kernel subsystems.

Normally industrial automatic control tasks are run in a userspace
thread with some realtime priority.

As Kent says, in-kernel events are exclusively using IRQ as
mechanism, and should be modeled as IRQs. Then the question
is how you join the timestamp with the IRQ. GPIO chips are
just some kind of irqchip in this regard, we reuse the irqchip
infrastructure in the kernel for all GPIO drivers that generate
"events" in response to state transitions on digital lines.

> >> And certainly you will also want to use this timestamp for
> >> IIO devices? If it is just GPIOs and IRQs today, it will be
> >> gyroscopes and accelerometers tomorrow, am I right?
> >>
>
> Gyroscope, accelerometers or any IIO are built on top of i2c/spi and/or GPIOs.
> So they are covered as long as they serve as client to GTE framework, For
> example, if gyroscope uses GPIO as an interrupt to indicate frame
> ready, GTE could timestamp that GPIO as well any IRQs like i2c transaction
> complete IRQ. To this to happen, gycroscope then register itself with
> GTE framework and enable required signals that it interfaces/interested with.

I think there are IIO devices that provide their own
hardware timestamp and as such they might want to use that,
so the mechanism need to be generic enough that a certain
hardware timestamp can be selected sooner or later.
But let's not overcomplicate things for now.

Yours,
Linus Walleij