linux-kernel - Re: [PATCH 1/2] iio: light: ltr390: Add sysfs attribute to report data freshness

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: <CAE3SzaTG-re2HPRAcPWuo2YmM9mxLWndpN_SQOAZg7MP_B3xDg@mail.gmail.com>
Date: Tue, 22 Jul 2025 09:25:02 +0530
From: Akshay Jindal <akshayaj.lkd@...il.com>
To: David Lechner <dlechner@...libre.com>
Cc: anshulusr@...il.com, jic23@...nel.org, nuno.sa@...log.com, andy@...nel.org, 
	shuah@...nel.org, linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] iio: light: ltr390: Add sysfs attribute to report
 data freshness

Thanks David for the swift and valuable feedback. Please find replies inline.

On Tue, Jul 22, 2025 at 1:55 AM David Lechner <dlechner@...libre.com> wrote:
>
> For debugging, using debugfs would make more sense.
Will it make sense if I simply give register access via debugfs?
Something like this:
static const struct iio_info ad7606_info_sw_mode = {
    .read_raw = &ad7606_read_raw,
    .write_raw = &ad7606_write_raw,
    .debugfs_reg_access = &ad7606_reg_access,<---------
    .validate_trigger = &ad7606_validate_trigger,
    .update_scan_mode = &ad7606_update_scan_mode,
};
This way the information about data status will be available on demand,
without exposing any special sysfs attribute.
>
> For application level filtering, why does it matter if we have
> read the same value before or not? The sampling_frequency is
> available, so the application should be able to deduce when
> fresh data should be available based on time.
Agreed.
>
> I could see maybe polling this in the kernel in order to implement
> a buffered capture mode, but not sure passing this on to userspace
> is the best way to go about it.
I had sent 2 patches. This was my PATCH 1 of 2. In patch 2 of 2,
I have done something similar to what you mentioned, not exactly polling,
but reading the data status bit before reading actual data.
Both patches are independent. Please have a look at that as well.

Thanks,
Akshay