linux-kernel - Re: [PATCH RFC 0/9] iio: Introduce new timestamp grabbing APIs

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: <20250531191048.176b40af@jic23-huawei>
Date: Sat, 31 May 2025 19:10:48 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Gyeyoung Baek <gye976@...il.com>
Cc: David Lechner <dlechner@...libre.com>, Nuno Sá
 <nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/9] iio: Introduce new timestamp grabbing APIs

On Mon, 19 May 2025 23:25:52 +0900
Gyeyoung Baek <gye976@...il.com> wrote:

> Support automatic timestamp grabbing by passing `true` to the `timestamp_enabled` parameter of `iio_triggered_buffer_setup_new()`.
> So consumer drivers don't need to set `iio_pollfunc_store_time()` as either the tophalf or bottomhalf manually.
> 
> For this, triggers must indicate whether they will call `poll()`, `poll_nested()`, or both before
> calling `iio_trigger_register()`. This is necessary because the consumer's handler does not know
> in advance which trigger will be attached.
> 
> Once `iio_trigger_attach_poll_func()` is called, a timestamp is grabbed in either the
> tophalf or bottomhalf based on the trigger's type (POLL or POLL_NESTED). If the trigger
> supports both (e.g., at91-sama5d2-adc.c), it is treated as POLL_NESTED since the consumer's
> tophalf is not invoked in poll_nested(), but the bottomhalf always is.
> 
> If the attached trigger supports timestamp grabbing itself, the consumer does not need to handle it.
> Instead, the consumer's `poll_func` pointer is passed to the trigger, which can then store the
> timestamp directly into consumer. Trigger drivers can pass timestamp values to consumers in a consistent
> interface using the new API `iio_trigger_store_time()`.

This trigger grabbing timestamps thing seems to me to a potential future
optimization.  I'm not seeing why we need it for the fundamental thing we
are addressing here and it is making the patch set more confusing for me
at least.

> 
> Tested on qemu, with dummy and trig-sysfs drivers tweaked for testing.
> 
> Signed-off-by: Gyeyoung Baek <gye976@...il.com>
> ---
> Gyeyoung Baek (9):
>       iio: buffer: Fix checkpatch.pl warning
>       iio: consumer: Define timestamp-related structures and constants
>       iio: consumer: Add new APIs of triggered_buffer_setup() family
>       iio: consumer: Add new API iio_poll_func_register()
>       iio: consumer: Add new API iio_pollfunc_get_timestamp()
>       iio: trigger: Define timetamp-related structures and constants
>       iio: trigger: Add new API iio_trigger_attach_timestamp()
>       iio: trigger: Add new API iio_trigger_store_time()
>       iio: rpr0521: Use new timestamp-related APIs
> 
>  drivers/iio/buffer/industrialio-triggered-buffer.c |  84 ++++++++++++-
>  drivers/iio/industrialio-trigger.c                 | 135 ++++++++++++++++++++-
>  drivers/iio/light/rpr0521.c                        |  22 +---
>  include/linux/iio/trigger.h                        |  16 ++-
>  include/linux/iio/trigger_consumer.h               |  23 ++++
>  include/linux/iio/triggered_buffer.h               |  25 ++++
>  6 files changed, 283 insertions(+), 22 deletions(-)
> ---
> base-commit: 43a9eee06bf8a8535d8709b29379bec8cafcab56
> change-id: 20250518-timestamp-a899e78e07e3
> 
> Best regards,