From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>

When interrupt timestamp interval is not valid, we use an estimated value
that can in rare case be bigger than the interrupt timestamp. This is
obviously wrong, so better use interrupt timestamp in this case.

Fixes: 8f4b627656fa ("iio: inv_sensors: better timestamp alignment when using watermark")
Cc: stable@vger.kernel.org
Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
---
 drivers/iio/common/inv_sensors/inv_sensors_timestamp.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c b/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c
index 88a82d1370c5..8c9e81a77e68 100644
--- a/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c
+++ b/drivers/iio/common/inv_sensors/inv_sensors_timestamp.c
@@ -167,11 +167,16 @@ void inv_sensors_timestamp_interrupt(struct inv_sensors_timestamp *ts,
 		valid = inv_validate_period(ts, period);
 	}
 
-	/* if interrupt interval is valid, sync with interrupt timestamp */
+	/*
+	 * If interrupt interval is valid, sync with interrupt timestamp.
+	 * Otherwise, use estimated value while ensuring interrupt timestamp
+	 * remains the maximum possible value.
+	 */
+	period = inv_align_timestamp_it(ts, sample_nb);
 	if (valid)
-		ts->period = inv_align_timestamp_it(ts, sample_nb);
+		ts->period = period;
 	else
-		ts->period = ts->mult * ts->chip_period.val;
+		ts->period = min(ts->mult * ts->chip_period.val, period);
 }
 EXPORT_SYMBOL_NS_GPL(inv_sensors_timestamp_interrupt, "IIO_INV_SENSORS_TIMESTAMP");
 

---
base-commit: 22359083a9e74d538ce383d5c0ee30cc20182187
change-id: 20260824-iio-common-inv-sensors-fix-estimated-use-147d698d2858

Best regards,
--  
Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>

On Mon, Aug 24, 2026 at 05:16:58PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:

> When interrupt timestamp interval is not valid, we use an estimated value
> that can in rare case be bigger than the interrupt timestamp. This is
> obviously wrong, so better use interrupt timestamp in this case.

...

> -		ts->period = ts->mult * ts->chip_period.val;
> +		ts->period = min(ts->mult * ts->chip_period.val, period);

It's u32 * u32, how is this guaranteed to be always under the u32 result?

-- 
With Best Regards,
Andy Shevchenko