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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87h7l1k9yi.wl-maz@kernel.org>
Date:   Tue, 23 Mar 2021 18:21:09 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Dipen Patel <dipenp@...dia.com>,
        Kent Gibson <warthog618@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        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 Tue, 23 Mar 2021 10:06:39 +0000,
Thierry Reding <thierry.reding@...il.com> wrote:

[...]

> Obviously if we don't integrate this with IRQs directly, it becomes a
> bit more difficult to relate the captured timestamps to the events
> across subsystem boundaries. I'm not sure how this would be solved
> properly. If the events are sufficiently rare, and it's certain that
> none will be missed, then it should be possible to just pull a timestamp
> from the timestamp FIFO for each event.
> 
> All of that said, I wonder if perhaps hierarchical IRQ domains can
> somehow be used for this. We did something similar on Tegra not too long
> ago for wake events, which are basically IRQs exposed by a parent IRQ
> chip that allows waking up from system sleep. There are some
> similarities between that and GTE in that the wake events also map to a
> subset of GPIOs and IRQs and provide additional functionalities on top.
> 
> I managed to mess up the implementation and Marc stepped in to clean
> things up, so Cc'ing him since he's clearly more familiar with the topic
> than I am.

Sure, but I'm pretty clueless when it comes to what this GTE thing
does (it has a fast car ring to it, which isn't a selling point for
me... ;-).

If, as I understand it, it is supposed to collect timestamps on
signalling of IRQs, you could make it part of the kernel's view of the
interrupt path by "pushing" a domain on top of the IRQ stack,
triggering the configuration/timestamping of this interrupt.

What is completely unclear to me is how you extract information from
it. The IRQ doesn't really give you an interface to extract a lot of
information aside from an interrupt count and what is defined as the
interrupt state. A timestamp doesn't really count as state, so you'd
need to invent something new here.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.