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

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

[Akshay Jindal]

Some IIO sensors provide a status bit indicating whether the current data
register holds freshly measured data or stale data previously read.

Expose this status via a new read-only sysfs attribute, 'data_fresh',
which returns:
  - 1 if the data is freshly sampled
  - 0 if the data is stale

This attribute allows userspace to observe data freshness directly, which
can be useful for debugging or application-level filtering.

Document the attribute under Documentation/ABI/testing/sysfs-bus-iio.

Signed-off-by: Akshay Jindal <akshayaj.lkd@gmail.com>
---
Testing details:
================
-> Tested on Raspberrypi 4B. Follow for more details.

akshayajpi@raspberrypi:~ $ uname -r
6.12.35-v8+
akshayajpi@raspberrypi:~ $ uname -a
Linux raspberrypi 6.12.35-v8+ #5 SMP PREEMPT Tue Jul 15 17:38:06 IST 2025 aarch64 GNU/Linux

-> Sensor Detection, overlaying of device tree and Driver loading
akshayajpi@raspberrypi:~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- 53 -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

akshayajpi@raspberrypi:~ $ sudo dtoverlay i2c-sensor ltr390
akshayajpi@raspberrypi:~ $ lsmod|grep ltr390
ltr390                 16384  0
industrialio          110592  1 ltr390
regmap_i2c             12288  1 ltr390

-> Sysfs Attribute Creation validation
akshayajpi@raspberrypi:~ $ ls -ltrh /sys/bus/iio/devices/iio\:device0/
total 0
-rw-r--r-- 1 root root 4.0K Jul 21 21:41 uevent
-r--r--r-- 1 root root 4.0K Jul 21 21:41 name
lrwxrwxrwx 1 root root    0 Jul 21 21:42 of_node -> ../../../../../../../firmware/devicetree/base/soc/i2c@7e804000/ltr390@53
-rw-r--r-- 1 root root 4.0K Jul 21 21:42 integration_time
-r--r--r-- 1 root root 4.0K Jul 21 21:42 waiting_for_supplier
lrwxrwxrwx 1 root root    0 Jul 21 21:42 subsystem -> ../../../../../../../bus/iio
-r--r--r-- 1 root root 4.0K Jul 21 21:42 scale_available
-r--r--r-- 1 root root 4.0K Jul 21 21:42 sampling_frequency_available
-rw-r--r-- 1 root root 4.0K Jul 21 21:42 sampling_frequency
drwxr-xr-x 2 root root    0 Jul 21 21:42 power
-rw-r--r-- 1 root root 4.0K Jul 21 21:42 in_uvindex_scale
-rw-r--r-- 1 root root 4.0K Jul 21 21:42 in_uvindex_raw
-r--r--r-- 1 root root 4.0K Jul 21 21:42 integration_time_available
-rw-r--r-- 1 root root 4.0K Jul 21 21:42 in_illuminance_scale
-rw-r--r-- 1 root root 4.0K Jul 21 21:42 in_illuminance_raw
drwxr-xr-x 2 root root    0 Jul 21 21:42 events
-r--r--r-- 1 root root 4.0K Jul 21 21:42 dev
-r--r--r-- 1 root root 4.0K Jul 21 21:42 data_fresh<-----

-> Disabled Bit 1 in MAIN_CTRL (reg 0x0) register to stop fresh measurements
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
609
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
603
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh
1
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh
1
akshayajpi@raspberrypi:~ $ i2cget -f -y 1 0x53 0x0
0x02
akshayajpi@raspberrypi:~ $ i2cset -f -y 1 0x53 0x0 0x0
akshayajpi@raspberrypi:~ $ i2cget -f -y 1 0x53 0x0
0x00

-> data_status bit cleared after reading
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh
1
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh
0
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh
0
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
605
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
605

-> Re-enabled sensor and fresh measurements reported
akshayajpi@raspberrypi:~ $ i2cset -f -y 1 0x53 0x0 0x2
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh
1
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh
1
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
607
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
622

 Documentation/ABI/testing/sysfs-bus-iio | 14 +++++++++++
 drivers/iio/light/ltr390.c              | 33 +++++++++++++++++++++++++
 2 files changed, 47 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 190bfcc1e836..5d176d46c15d 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -2383,3 +2383,17 @@ Description:
 		Value representing the user's attention to the system expressed
 		in units as percentage. This usually means if the user is
 		looking at the screen or not.
+
+What:		/sys/.../iio:deviceX/data_fresh
+KernelVersion:	6.16
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Read-only attribute indicating whether the sensor data currently
+		available in the device is freshly measured or stale.
+
+		Returns:
+			1 - Data is freshly measured
+			0 - Data is stale (previously read or not yet updated)
+
+		Provides userspace visibility into data_freshness status which
+		can be used for debugging and informational use.
diff --git a/drivers/iio/light/ltr390.c b/drivers/iio/light/ltr390.c
index ee59bbb8aa09..5af0ffd3df1d 100644
--- a/drivers/iio/light/ltr390.c
+++ b/drivers/iio/light/ltr390.c
@@ -30,6 +30,7 @@
 
 #include <linux/iio/iio.h>
 #include <linux/iio/events.h>
+#include <linux/iio/sysfs.h>
 
 #include <linux/unaligned.h>
 
@@ -61,6 +62,7 @@
 
 #define LTR390_FRACTIONAL_PRECISION 100
 
+#define LTR390_DATA_STATUS_MASK		BIT(3)
 /*
  * At 20-bit resolution (integration time: 400ms) and 18x gain, 2300 counts of
  * the sensor are equal to 1 UV Index [Datasheet Page#8].
@@ -178,6 +180,36 @@ static int ltr390_get_samp_freq_or_period(struct ltr390_data *data,
 	return ltr390_samp_freq_table[value][option];
 }
 
+/*
+ * Indicates whether the most recent sensor data read from the device
+ * was freshly measured (1) or stale/old (0). This is based on ltr390's
+ * internal data status bit.
+ */
+static ssize_t data_fresh_show(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	int ret, status;
+	struct ltr390_data *data = iio_priv(dev_to_iio_dev(dev));
+
+	ret = ltr390_register_read(data, LTR390_MAIN_STATUS);
+	if (ret < 0)
+		return ret;
+
+	status = ret;
+	return sysfs_emit(buf, "%d\n", !!(status & LTR390_DATA_STATUS_MASK));
+}
+
+static IIO_DEVICE_ATTR_RO(data_fresh, 0);
+
+static struct attribute *ltr390_attributes[] = {
+	&iio_dev_attr_data_fresh.dev_attr.attr,
+	NULL
+};
+
+static const struct attribute_group ltr390_attribute_group = {
+	.attrs = ltr390_attributes,
+};
+
 static int ltr390_read_raw(struct iio_dev *iio_device,
 			   struct iio_chan_spec const *chan, int *val,
 			   int *val2, long mask)
@@ -594,6 +626,7 @@ static const struct iio_info ltr390_info = {
 	.read_event_config = ltr390_read_event_config,
 	.write_event_value = ltr390_write_event_value,
 	.write_event_config = ltr390_write_event_config,
+	.attrs = &ltr390_attribute_group,
 };
 
 static irqreturn_t ltr390_interrupt_handler(int irq, void *private)
-- 
2.43.0

[PATCH 2/2] iio: light: ltr390: Add conditional data freshness check with sysfs control

[Akshay Jindal]

Add logic to check the sensor’s data freshness status bit before reading
data, and skip reads if the data is stale.

Introduce a new boolean sysfs attribute, `data_fresh_check_enable`, to allow
users to enable or disable this behavior at runtime:

  - 1: Enable data freshness check (default)
  - 0: Disable data freshness check

This provides flexibility to choose between ensuring fresh data and allowing
faster reads when occasional staleness is acceptable.

Document the new attribute under Documentation/ABI/testing/sysfs-bus-iio.

Signed-off-by: Akshay Jindal <akshayaj.lkd@gmail.com>
---
-> Tested on Raspberrypi 4B. Follow for more details.

akshayajpi@raspberrypi:~ $ uname -r
6.12.35-v8+
akshayajpi@raspberrypi:~ $ uname -a
Linux raspberrypi 6.12.35-v8+ #5 SMP PREEMPT Tue Jul 15 17:38:06 IST 2025 aarch64 GNU/Linux

-> Sensor Detection, overlaying of device tree and Driver loading
akshayajpi@raspberrypi:~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- 53 -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
akshayajpi@raspberrypi:~ $ sudo dtoverlay i2c-sensor ltr390
akshayajpi@raspberrypi:~ $ lsmod|grep ltr390
ltr390                 16384  0
industrialio          110592  1 ltr390
regmap_i2c             12288  1 ltr390

-> Sysfs Attribute Creation validation
akshayajpi@raspberrypi:~ $ ls -ltrh /sys/bus/iio/devices/iio\:device0/
total 0
-rw-r--r-- 1 root root 4.0K Jul 21 23:52 uevent
-r--r--r-- 1 root root 4.0K Jul 21 23:52 name
-r--r--r-- 1 root root 4.0K Jul 21 23:52 waiting_for_supplier
lrwxrwxrwx 1 root root    0 Jul 21 23:52 subsystem -> ../../../../../../../bus/iio
-r--r--r-- 1 root root 4.0K Jul 21 23:52 scale_available
-r--r--r-- 1 root root 4.0K Jul 21 23:52 sampling_frequency_available
-rw-r--r-- 1 root root 4.0K Jul 21 23:52 sampling_frequency
drwxr-xr-x 2 root root    0 Jul 21 23:52 power
lrwxrwxrwx 1 root root    0 Jul 21 23:52 of_node -> ../../../../../../../firmware/devicetree/base/soc/i2c@7e804000/ltr390@53
-rw-r--r-- 1 root root 4.0K Jul 21 23:52 in_uvindex_scale
-rw-r--r-- 1 root root 4.0K Jul 21 23:52 in_uvindex_raw
-r--r--r-- 1 root root 4.0K Jul 21 23:52 integration_time_available
-rw-r--r-- 1 root root 4.0K Jul 21 23:52 integration_time
-rw-r--r-- 1 root root 4.0K Jul 21 23:52 in_illuminance_scale
-rw-r--r-- 1 root root 4.0K Jul 21 23:52 in_illuminance_raw
drwxr-xr-x 2 root root    0 Jul 21 23:52 events
-r--r--r-- 1 root root 4.0K Jul 21 23:52 dev
-rw-r--r-- 1 root root 4.0K Jul 21 23:52 data_fresh_check_enable<-----
-r--r--r-- 1 root root 4.0K Jul 21 23:52 data_fresh

-> Default value 1 for data_fresh_check_enable
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh
1
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable 
1

-> Disable fresh measurement in the sensor
akshayajpi@raspberrypi:~ $ i2cset -f -y 1 0x53 0x0 0x0
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable 
1
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable 
1
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
647
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh
0

-> Since data_fresh_enable_check is enabled by default, driver skips
   stale data read and emits -EAGAIN.
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
cat: '/sys/bus/iio/devices/iio:device0/in_illuminance_raw': Resource temporarily unavailable
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
cat: '/sys/bus/iio/devices/iio:device0/in_illuminance_raw': Resource temporarily unavailable
akshayajpi@raspberrypi:~ $ 

-> Disable data_fresh_check_en
akshayajpi@raspberrypi:~ $ echo 0 | sudo tee /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable
0
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable
0
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh
0

-> Since freshness check is disabled, driver reads and prints stale
   data.
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
647
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
647
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
647

-> Re-enabling freshness check, results in driver emitting -EAGAIN.
akshayajpi@raspberrypi:~ $ echo 1 | sudo tee /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable
1
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable
1
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
cat: '/sys/bus/iio/devices/iio:device0/in_illuminance_raw': Resource temporarily unavailable
akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
cat: '/sys/bus/iio/devices/iio:device0/in_illuminance_raw': Resource temporarily unavailable

 Documentation/ABI/testing/sysfs-bus-iio | 12 ++++++
 drivers/iio/light/ltr390.c              | 55 ++++++++++++++++++++++++-
 2 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 5d176d46c15d..da881e16ee3d 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -2397,3 +2397,15 @@ Description:
 
 		Provides userspace visibility into data_freshness status which
 		can be used for debugging and informational use.
+
+What:		/sys/.../iio:deviceX/data_fresh_check_enable
+KernelVersion:	6.16
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Read-write boolean attribute controlling whether the driver
+		checks the data freshness status bit before reading sensor data.
+
+		0 - Freshness check disabled
+		1 - Enable check; driver will skip reading stale data (default)
+
+		This flag affects the behavior of data reads.
diff --git a/drivers/iio/light/ltr390.c b/drivers/iio/light/ltr390.c
index 5af0ffd3df1d..b13f01835aeb 100644
--- a/drivers/iio/light/ltr390.c
+++ b/drivers/iio/light/ltr390.c
@@ -98,6 +98,7 @@ struct ltr390_data {
 	enum ltr390_mode mode;
 	int gain;
 	int int_time_us;
+	bool data_fresh_check_en;
 };
 
 static const struct regmap_config ltr390_regmap_config = {
@@ -199,10 +200,40 @@ static ssize_t data_fresh_show(struct device *dev,
 	return sysfs_emit(buf, "%d\n", !!(status & LTR390_DATA_STATUS_MASK));
 }
 
+static ssize_t data_fresh_check_enable_show(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	struct ltr390_data *data = iio_priv(dev_to_iio_dev(dev));
+
+	guard(mutex)(&data->lock);
+
+	return sysfs_emit(buf, "%d\n", data->data_fresh_check_en);
+}
+
+static ssize_t data_fresh_check_enable_store(struct device *dev,
+		struct device_attribute *attr,
+		const char *buf, size_t len)
+{
+	int ret;
+	bool data_fresh_check_en;
+	struct ltr390_data *data = iio_priv(dev_to_iio_dev(dev));
+
+	ret = kstrtobool(buf, &data_fresh_check_en);
+	if (ret)
+		return ret;
+
+	guard(mutex)(&data->lock);
+
+	data->data_fresh_check_en = data_fresh_check_en;
+	return len;
+}
+
 static IIO_DEVICE_ATTR_RO(data_fresh, 0);
+static IIO_DEVICE_ATTR_RW(data_fresh_check_enable, 0);
 
 static struct attribute *ltr390_attributes[] = {
 	&iio_dev_attr_data_fresh.dev_attr.attr,
+	&iio_dev_attr_data_fresh_check_enable.dev_attr.attr,
 	NULL
 };
 
@@ -214,7 +245,7 @@ static int ltr390_read_raw(struct iio_dev *iio_device,
 			   struct iio_chan_spec const *chan, int *val,
 			   int *val2, long mask)
 {
-	int ret;
+	int ret, status;
 	struct ltr390_data *data = iio_priv(iio_device);
 
 	guard(mutex)(&data->lock);
@@ -226,6 +257,16 @@ static int ltr390_read_raw(struct iio_dev *iio_device,
 			if (ret < 0)
 				return ret;
 
+			if (data->data_fresh_check_en) {
+				ret = ltr390_register_read(data, LTR390_MAIN_STATUS);
+				if (ret < 0)
+					return ret;
+
+				status = ret;
+				if (!(status & LTR390_DATA_STATUS_MASK))
+					return -EAGAIN;
+			}
+
 			ret = ltr390_register_read(data, LTR390_UVS_DATA);
 			if (ret < 0)
 				return ret;
@@ -236,6 +277,16 @@ static int ltr390_read_raw(struct iio_dev *iio_device,
 			if (ret < 0)
 				return ret;
 
+			if (data->data_fresh_check_en) {
+				ret = ltr390_register_read(data, LTR390_MAIN_STATUS);
+				if (ret < 0)
+					return ret;
+
+				status = ret;
+				if (!(status & LTR390_DATA_STATUS_MASK))
+					return -EAGAIN;
+			}
+
 			ret = ltr390_register_read(data, LTR390_ALS_DATA);
 			if (ret < 0)
 				return ret;
@@ -687,6 +738,8 @@ static int ltr390_probe(struct i2c_client *client)
 	data->gain = 3;
 	/* default mode for ltr390 is ALS mode */
 	data->mode = LTR390_SET_ALS_MODE;
+	/* default value for data_fresh_check_en is 1 */
+	data->data_fresh_check_en = 1;
 
 	mutex_init(&data->lock);
 
-- 
2.43.0

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

[David Lechner]

On 7/21/25 2:54 PM, Akshay Jindal wrote:
> Some IIO sensors provide a status bit indicating whether the current data
> register holds freshly measured data or stale data previously read.
> 
> Expose this status via a new read-only sysfs attribute, 'data_fresh',
> which returns:
>   - 1 if the data is freshly sampled
>   - 0 if the data is stale
> 
> This attribute allows userspace to observe data freshness directly, which
> can be useful for debugging or application-level filtering.

For debugging, using debugfs would make more sense.

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.

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.

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

[Akshay Jindal]

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

On Tue, Jul 22, 2025 at 1:55 AM David Lechner <dlechner@baylibre.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

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

[David Lechner]

On 7/21/25 10:55 PM, Akshay Jindal wrote:
> Thanks David for the swift and valuable feedback. Please find replies inline.
> 
> On Tue, Jul 22, 2025 at 1:55 AM David Lechner <dlechner@baylibre.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.

Yes, this would be fine.

>>
>> 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,

Here is what the IIO docs have to say about it (reading the in_light_raw
attribute is considered INDIO_DIRECT_MODE):

 * @INDIO_DIRECT_MODE: There is an access to either:
 * a) The last single value available for devices that do not provide
 *    on-demand reads.
 * b) A new value after performing an on-demand read otherwise.
 * On most devices, this is a single-shot read. On some devices with data
 * streams without an 'on-demand' function, this might also be the 'last value'
 * feature. Above all, this mode internally means that we are not in any of the
 * other modes, and sysfs reads should work.
 * Device drivers should inform the core if they support this mode.

So I don't think the current implementation is really in violation
of this.

Additionally, changes you proposed in patch 2/2 would break existing
users by returning an error when it didn't used to, so we couldn't
accept that.

If this was a new driver, we might consider having the raw read
poll for fresh data so that each read was guaranteed to be new
data, but even that change in timing could break existing users,
so probably not something we would want to do now.


I still think there is a reasonable workaround of just having userspace
wait for the sample period between reads to guarantee fresh data
without changing the driver at all.


> but reading the data status bit before reading actual data.
> Both patches are independent. Please have a look at that as well.
> 
> Thanks,
> Akshay

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

[Andy Shevchenko]

On Tue, Jul 22, 2025 at 01:24:18AM +0530, Akshay Jindal wrote:
> Some IIO sensors provide a status bit indicating whether the current data
> register holds freshly measured data or stale data previously read.
> 
> Expose this status via a new read-only sysfs attribute, 'data_fresh',
> which returns:
>   - 1 if the data is freshly sampled
>   - 0 if the data is stale
> 
> This attribute allows userspace to observe data freshness directly, which
> can be useful for debugging or application-level filtering.
> 
> Document the attribute under Documentation/ABI/testing/sysfs-bus-iio.

> +What:		/sys/.../iio:deviceX/data_fresh
> +KernelVersion:	6.16

No way it can make this version. Neither v6.17 if I understood that this
feature is proposed in this patch.

> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Read-only attribute indicating whether the sensor data currently
> +		available in the device is freshly measured or stale.
> +
> +		Returns:
> +			1 - Data is freshly measured
> +			0 - Data is stale (previously read or not yet updated)
> +
> +		Provides userspace visibility into data_freshness status which
> +		can be used for debugging and informational use.

...

>  
> +#define LTR390_DATA_STATUS_MASK		BIT(3)

Missing blank line.

>  /*
>   * At 20-bit resolution (integration time: 400ms) and 18x gain, 2300 counts of
>   * the sensor are equal to 1 UV Index [Datasheet Page#8].

-- 
With Best Regards,
Andy Shevchenko

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

[Jonathan Cameron]

On Tue, 22 Jul 2025 16:15:55 -0500
David Lechner <dlechner@baylibre.com> wrote:

> On 7/21/25 10:55 PM, Akshay Jindal wrote:
> > Thanks David for the swift and valuable feedback. Please find replies inline.
> > 
> > On Tue, Jul 22, 2025 at 1:55 AM David Lechner <dlechner@baylibre.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.  
> 
> Yes, this would be fine.
> 
> >>
> >> 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,  
> 
> Here is what the IIO docs have to say about it (reading the in_light_raw
> attribute is considered INDIO_DIRECT_MODE):
> 
>  * @INDIO_DIRECT_MODE: There is an access to either:
>  * a) The last single value available for devices that do not provide
>  *    on-demand reads.
>  * b) A new value after performing an on-demand read otherwise.
>  * On most devices, this is a single-shot read. On some devices with data
>  * streams without an 'on-demand' function, this might also be the 'last value'
>  * feature. Above all, this mode internally means that we are not in any of the
>  * other modes, and sysfs reads should work.
>  * Device drivers should inform the core if they support this mode.
> 
> So I don't think the current implementation is really in violation
> of this.
> 
> Additionally, changes you proposed in patch 2/2 would break existing
> users by returning an error when it didn't used to, so we couldn't
> accept that.
> 
> If this was a new driver, we might consider having the raw read
> poll for fresh data so that each read was guaranteed to be new
> data, but even that change in timing could break existing users,
> so probably not something we would want to do now.
> 
> 
> I still think there is a reasonable workaround of just having userspace
> wait for the sample period between reads to guarantee fresh data
> without changing the driver at all.
> 

Agreed.  Is the interrupt wired on this board?  If it is and you
want to do filtering with the knowledge that the data is fresh then
add a data ready trigger and buffered capture support.
It's a much bigger job, but it is standard ABI and as such of more
general use.

Jonathan


> 
> > but reading the data status bit before reading actual data.
> > Both patches are independent. Please have a look at that as well.
> > 
> > Thanks,
> > Akshay  
> 
> 

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

[Akshay Jindal]

On Thu, Jul 24, 2025 at 6:09 PM Jonathan Cameron <jic23@kernel.org> wrote:
> Agreed.  Is the interrupt wired on this board?  If it is and you
> want to do filtering with the knowledge that the data is fresh then
> add a data ready trigger and buffered capture support.
> It's a much bigger job, but it is standard ABI and as such of more
> general use.
>
> Jonathan
>
Yes, the interrupt is wired in and enabled.

For LTR390, data_freshness is not the same as data-ready.
Here the sensor does not support a data-ready interrupt.
It only supports threshold violation interrupts where thresholds are
configurable.
LTR390 datasheet Pg 17:
https://optoelectronics.liteon.com/upload/download/DS86-2015-0004/LTR-390UV_Final_%20DS_V1%201.pdf

Correct me, if I am wrong, but as per my understanding, trigger based interrupts
are more appropriate where the application requires storing multiple samples
in a buffer at specific time intervals, provided the sensor supports
data-ready interrupts.


Thanks,
Akshay

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

[David Lechner]

On 7/24/25 11:55 AM, Akshay Jindal wrote:
> On Thu, Jul 24, 2025 at 6:09 PM Jonathan Cameron <jic23@kernel.org> wrote:
>> Agreed.  Is the interrupt wired on this board?  If it is and you
>> want to do filtering with the knowledge that the data is fresh then
>> add a data ready trigger and buffered capture support.
>> It's a much bigger job, but it is standard ABI and as such of more
>> general use.
>>
>> Jonathan
>>
> Yes, the interrupt is wired in and enabled.
> 
> For LTR390, data_freshness is not the same as data-ready.
> Here the sensor does not support a data-ready interrupt.
> It only supports threshold violation interrupts where thresholds are
> configurable.
> LTR390 datasheet Pg 17:
> https://optoelectronics.liteon.com/upload/download/DS86-2015-0004/LTR-390UV_Final_%20DS_V1%201.pdf
> 
> Correct me, if I am wrong, but as per my understanding, trigger based interrupts
> are more appropriate where the application requires storing multiple samples
> in a buffer at specific time intervals, provided the sensor supports
> data-ready interrupts.
> 

Interrupts works just as well for single samples when devices have a
data ready signal. But you are right, that doesn't help us here
since the interrupt is just for threshold alerts.

Re: [PATCH 2/2] iio: light: ltr390: Add conditional data freshness check with sysfs control

[Akshay Jindal]

On Tue, Jul 22, 2025 at 1:25 AM Akshay Jindal <akshayaj.lkd@gmail.com> wrote:
>
> Add logic to check the sensor’s data freshness status bit before reading
> data, and skip reads if the data is stale.
>
> Introduce a new boolean sysfs attribute, `data_fresh_check_enable`, to allow
> users to enable or disable this behavior at runtime:
>
>   - 1: Enable data freshness check (default)
>   - 0: Disable data freshness check
>
> This provides flexibility to choose between ensuring fresh data and allowing
> faster reads when occasional staleness is acceptable.
>
> Document the new attribute under Documentation/ABI/testing/sysfs-bus-iio.
>
> Signed-off-by: Akshay Jindal <akshayaj.lkd@gmail.com>
> ---
> -> Tested on Raspberrypi 4B. Follow for more details.
>
> akshayajpi@raspberrypi:~ $ uname -r
> 6.12.35-v8+
> akshayajpi@raspberrypi:~ $ uname -a
> Linux raspberrypi 6.12.35-v8+ #5 SMP PREEMPT Tue Jul 15 17:38:06 IST 2025 aarch64 GNU/Linux
>
> -> Sensor Detection, overlaying of device tree and Driver loading
> akshayajpi@raspberrypi:~ $ i2cdetect -y 1
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:                         -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- 53 -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
> akshayajpi@raspberrypi:~ $ sudo dtoverlay i2c-sensor ltr390
> akshayajpi@raspberrypi:~ $ lsmod|grep ltr390
> ltr390                 16384  0
> industrialio          110592  1 ltr390
> regmap_i2c             12288  1 ltr390
>
> -> Sysfs Attribute Creation validation
> akshayajpi@raspberrypi:~ $ ls -ltrh /sys/bus/iio/devices/iio\:device0/
> total 0
> -rw-r--r-- 1 root root 4.0K Jul 21 23:52 uevent
> -r--r--r-- 1 root root 4.0K Jul 21 23:52 name
> -r--r--r-- 1 root root 4.0K Jul 21 23:52 waiting_for_supplier
> lrwxrwxrwx 1 root root    0 Jul 21 23:52 subsystem -> ../../../../../../../bus/iio
> -r--r--r-- 1 root root 4.0K Jul 21 23:52 scale_available
> -r--r--r-- 1 root root 4.0K Jul 21 23:52 sampling_frequency_available
> -rw-r--r-- 1 root root 4.0K Jul 21 23:52 sampling_frequency
> drwxr-xr-x 2 root root    0 Jul 21 23:52 power
> lrwxrwxrwx 1 root root    0 Jul 21 23:52 of_node -> ../../../../../../../firmware/devicetree/base/soc/i2c@7e804000/ltr390@53
> -rw-r--r-- 1 root root 4.0K Jul 21 23:52 in_uvindex_scale
> -rw-r--r-- 1 root root 4.0K Jul 21 23:52 in_uvindex_raw
> -r--r--r-- 1 root root 4.0K Jul 21 23:52 integration_time_available
> -rw-r--r-- 1 root root 4.0K Jul 21 23:52 integration_time
> -rw-r--r-- 1 root root 4.0K Jul 21 23:52 in_illuminance_scale
> -rw-r--r-- 1 root root 4.0K Jul 21 23:52 in_illuminance_raw
> drwxr-xr-x 2 root root    0 Jul 21 23:52 events
> -r--r--r-- 1 root root 4.0K Jul 21 23:52 dev
> -rw-r--r-- 1 root root 4.0K Jul 21 23:52 data_fresh_check_enable<-----
> -r--r--r-- 1 root root 4.0K Jul 21 23:52 data_fresh
>
> -> Default value 1 for data_fresh_check_enable
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh
> 1
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable
> 1
>
> -> Disable fresh measurement in the sensor
> akshayajpi@raspberrypi:~ $ i2cset -f -y 1 0x53 0x0 0x0
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable
> 1
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable
> 1
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
> 647
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh
> 0
>
> -> Since data_fresh_enable_check is enabled by default, driver skips
>    stale data read and emits -EAGAIN.
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
> cat: '/sys/bus/iio/devices/iio:device0/in_illuminance_raw': Resource temporarily unavailable
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
> cat: '/sys/bus/iio/devices/iio:device0/in_illuminance_raw': Resource temporarily unavailable
> akshayajpi@raspberrypi:~ $
>
> -> Disable data_fresh_check_en
> akshayajpi@raspberrypi:~ $ echo 0 | sudo tee /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable
> 0
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable
> 0
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh
> 0
>
> -> Since freshness check is disabled, driver reads and prints stale
>    data.
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
> 647
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
> 647
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
> 647
>
> -> Re-enabling freshness check, results in driver emitting -EAGAIN.
> akshayajpi@raspberrypi:~ $ echo 1 | sudo tee /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable
> 1
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable
> 1
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
> cat: '/sys/bus/iio/devices/iio:device0/in_illuminance_raw': Resource temporarily unavailable
> akshayajpi@raspberrypi:~ $ cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
> cat: '/sys/bus/iio/devices/iio:device0/in_illuminance_raw': Resource temporarily unavailable
>
>  Documentation/ABI/testing/sysfs-bus-iio | 12 ++++++
>  drivers/iio/light/ltr390.c              | 55 ++++++++++++++++++++++++-
>  2 files changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> index 5d176d46c15d..da881e16ee3d 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -2397,3 +2397,15 @@ Description:
>
>                 Provides userspace visibility into data_freshness status which
>                 can be used for debugging and informational use.
> +
> +What:          /sys/.../iio:deviceX/data_fresh_check_enable
> +KernelVersion: 6.16
> +Contact:       linux-iio@vger.kernel.org
> +Description:
> +               Read-write boolean attribute controlling whether the driver
> +               checks the data freshness status bit before reading sensor data.
> +
> +               0 - Freshness check disabled
> +               1 - Enable check; driver will skip reading stale data (default)
> +
> +               This flag affects the behavior of data reads.
> diff --git a/drivers/iio/light/ltr390.c b/drivers/iio/light/ltr390.c
> index 5af0ffd3df1d..b13f01835aeb 100644
> --- a/drivers/iio/light/ltr390.c
> +++ b/drivers/iio/light/ltr390.c
> @@ -98,6 +98,7 @@ struct ltr390_data {
>         enum ltr390_mode mode;
>         int gain;
>         int int_time_us;
> +       bool data_fresh_check_en;
>  };
>
>  static const struct regmap_config ltr390_regmap_config = {
> @@ -199,10 +200,40 @@ static ssize_t data_fresh_show(struct device *dev,
>         return sysfs_emit(buf, "%d\n", !!(status & LTR390_DATA_STATUS_MASK));
>  }
>
> +static ssize_t data_fresh_check_enable_show(struct device *dev,
> +               struct device_attribute *attr, char *buf)
> +{
> +       struct ltr390_data *data = iio_priv(dev_to_iio_dev(dev));
> +
> +       guard(mutex)(&data->lock);
> +
> +       return sysfs_emit(buf, "%d\n", data->data_fresh_check_en);
> +}
> +
> +static ssize_t data_fresh_check_enable_store(struct device *dev,
> +               struct device_attribute *attr,
> +               const char *buf, size_t len)
> +{
> +       int ret;
> +       bool data_fresh_check_en;
> +       struct ltr390_data *data = iio_priv(dev_to_iio_dev(dev));
> +
> +       ret = kstrtobool(buf, &data_fresh_check_en);
> +       if (ret)
> +               return ret;
> +
> +       guard(mutex)(&data->lock);
> +
> +       data->data_fresh_check_en = data_fresh_check_en;
> +       return len;
> +}
> +
>  static IIO_DEVICE_ATTR_RO(data_fresh, 0);
> +static IIO_DEVICE_ATTR_RW(data_fresh_check_enable, 0);
>
>  static struct attribute *ltr390_attributes[] = {
>         &iio_dev_attr_data_fresh.dev_attr.attr,
> +       &iio_dev_attr_data_fresh_check_enable.dev_attr.attr,
>         NULL
>  };
>
> @@ -214,7 +245,7 @@ static int ltr390_read_raw(struct iio_dev *iio_device,
>                            struct iio_chan_spec const *chan, int *val,
>                            int *val2, long mask)
>  {
> -       int ret;
> +       int ret, status;
>         struct ltr390_data *data = iio_priv(iio_device);
>
>         guard(mutex)(&data->lock);
> @@ -226,6 +257,16 @@ static int ltr390_read_raw(struct iio_dev *iio_device,
>                         if (ret < 0)
>                                 return ret;
>
> +                       if (data->data_fresh_check_en) {
> +                               ret = ltr390_register_read(data, LTR390_MAIN_STATUS);
> +                               if (ret < 0)
> +                                       return ret;
> +
> +                               status = ret;
> +                               if (!(status & LTR390_DATA_STATUS_MASK))
> +                                       return -EAGAIN;
> +                       }
> +
>                         ret = ltr390_register_read(data, LTR390_UVS_DATA);
>                         if (ret < 0)
>                                 return ret;
> @@ -236,6 +277,16 @@ static int ltr390_read_raw(struct iio_dev *iio_device,
>                         if (ret < 0)
>                                 return ret;
>
> +                       if (data->data_fresh_check_en) {
> +                               ret = ltr390_register_read(data, LTR390_MAIN_STATUS);
> +                               if (ret < 0)
> +                                       return ret;
> +
> +                               status = ret;
> +                               if (!(status & LTR390_DATA_STATUS_MASK))
> +                                       return -EAGAIN;
> +                       }
> +
>                         ret = ltr390_register_read(data, LTR390_ALS_DATA);
>                         if (ret < 0)
>                                 return ret;
> @@ -687,6 +738,8 @@ static int ltr390_probe(struct i2c_client *client)
>         data->gain = 3;
>         /* default mode for ltr390 is ALS mode */
>         data->mode = LTR390_SET_ALS_MODE;
> +       /* default value for data_fresh_check_en is 1 */
> +       data->data_fresh_check_en = 1;
I agree that this will break the user behaviour.
Before dumping this off, I wanted to explore an idea.
What if this remains disabled by default, i.e. data->data_fresh_check_en = 0;
So this way the regular sensor read_data calls will not break, and
based on demand,
the application can configure the driver to check for data freshness,
by toggling the sysfs attribute to 1.
i.e. echo 1 | sudo tee /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable

Thanks,
Akshay

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

[Jonathan Cameron]

On Thu, 24 Jul 2025 12:41:48 -0500
David Lechner <dlechner@baylibre.com> wrote:

> On 7/24/25 11:55 AM, Akshay Jindal wrote:
> > On Thu, Jul 24, 2025 at 6:09 PM Jonathan Cameron <jic23@kernel.org> wrote:  
> >> Agreed.  Is the interrupt wired on this board?  If it is and you
> >> want to do filtering with the knowledge that the data is fresh then
> >> add a data ready trigger and buffered capture support.
> >> It's a much bigger job, but it is standard ABI and as such of more
> >> general use.
> >>
> >> Jonathan
> >>  
> > Yes, the interrupt is wired in and enabled.
> > 
> > For LTR390, data_freshness is not the same as data-ready.
> > Here the sensor does not support a data-ready interrupt.
> > It only supports threshold violation interrupts where thresholds are
> > configurable.
> > LTR390 datasheet Pg 17:
> > https://optoelectronics.liteon.com/upload/download/DS86-2015-0004/LTR-390UV_Final_%20DS_V1%201.pdf
> > 
> > Correct me, if I am wrong, but as per my understanding, trigger based interrupts
> > are more appropriate where the application requires storing multiple samples
> > in a buffer at specific time intervals, provided the sensor supports
> > data-ready interrupts.
> >   
> 
> Interrupts works just as well for single samples when devices have a
> data ready signal. But you are right, that doesn't help us here
> since the interrupt is just for threshold alerts.
> 

Yeah.  I got thrown by the adfruit docs that say the interrupt can serve
this purpose. Clearly not from the datasheet.

Jonathan

Re: [PATCH 2/2] iio: light: ltr390: Add conditional data freshness check with sysfs control

[Akshay Jindal]

On Fri, Jul 25, 2025 at 12:24 AM Akshay Jindal <akshayaj.lkd@gmail.com> wrote:
>
> I agree that this will break the user behaviour.
> Before dumping this off, I wanted to explore an idea.
> What if this remains disabled by default, i.e. data->data_fresh_check_en = 0;
> So this way the regular sensor read_data calls will not break, and
> based on demand,
> the application can configure the driver to check for data freshness,
> by toggling the sysfs attribute to 1.
> i.e. echo 1 | sudo tee /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable
>
Hi,
Is there any feedback on this?

Thanks,
Akshay.

Re: [PATCH 2/2] iio: light: ltr390: Add conditional data freshness check with sysfs control

[Jonathan Cameron]

On Mon, 28 Jul 2025 01:42:19 +0530
Akshay Jindal <akshayaj.lkd@gmail.com> wrote:

> On Fri, Jul 25, 2025 at 12:24 AM Akshay Jindal <akshayaj.lkd@gmail.com> wrote:
> >
> > I agree that this will break the user behaviour.
> > Before dumping this off, I wanted to explore an idea.
> > What if this remains disabled by default, i.e. data->data_fresh_check_en = 0;
> > So this way the regular sensor read_data calls will not break, and
> > based on demand,
> > the application can configure the driver to check for data freshness,
> > by toggling the sysfs attribute to 1.
> > i.e. echo 1 | sudo tee /sys/bus/iio/devices/iio\:device0/data_fresh_check_enable
> >  
> Hi,
> Is there any feedback on this?

It's a fairly esoteric interface in general. I'm not yet convinced there
is a reason to have such an indicator at all. Key here is that custom ABI
is (more or less) unused ABI that bit rots.

So I think there are three possible paths forwards
- Harden whatever algorithm you are feeding this data to so that it doesn't
  matter if you get occasional duplicate data. i.e. make it a userspace problem.
- Handle the complexity of a buffered interface with freshness guarantee.
  Basically that means polling for new data - typically checking at double
  the expected sampling frequency and only pushing to the buffers if the
  data is fresh.
- Propose generic support for such an indicator and show that it is useful
  for a couple of devices and how we'd retrofit into existing drivers
  cleanly.

Jonathan

> 
> Thanks,
> Akshay.