[PATCH] iio: inv_sensors: fix estimated value larger than interrupt timestamp

[PATCH] iio: inv_sensors: fix estimated value larger than interrupt timestamp

[Jean-Baptiste Maneyrol via B4 Relay]

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>

Re: [PATCH] iio: inv_sensors: fix estimated value larger than interrupt timestamp

[Andy Shevchenko]

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

Re: [PATCH] iio: inv_sensors: fix estimated value larger than interrupt timestamp

[Jean-Baptiste Maneyrol]

>
>
>________________________________________
>From: Andy Shevchenko <andriy.shevchenko@intel.com>
>Sent: Monday, August 24, 2026 17:32
>To: Jean-Baptiste Maneyrol
>Cc: Jonathan Cameron; David Lechner; Nuno Sá; Andy Shevchenko; Jonathan Cameron; linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org; stable@vger.kernel.org
>Subject: Re: [PATCH] iio: inv_sensors: fix estimated value larger than interrupt timestamp
>
>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 >
>ZjQcmQRYFpfptBannerStart
>This Message Is From an External Sender
>This message came from outside your organization.
>
>ZjQcmQRYFpfptBannerEnd
>
>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?

Hello Andy,

(ts->mult * ts->chip_period.val) is an estimation of the sampling period of
the chip in ns. It is limited by maximum setting 8kHz (125000) and minimum
setting 1.5625Hz (640000000), with a 2% margin. Meaning maximum value is
652800000, which is below the 32 bits limit.

ts->chip_period.val is an estimation of the internal frequency which is 8kHz.
It's value will always be around 125000, with a 2% margin. Maximum value
being 127500.

ts->mult will change from 8kHz setting (1) to 1.5625Hz setting (5120).

Thanks,
JB

>
>--
>With Best Regards,
>Andy Shevchenko
>
>
>
>

Re: [PATCH] iio: inv_sensors: fix estimated value larger than interrupt timestamp

[Jonathan Cameron]

On Tue, 25 Aug 2026 13:31:38 +0000
Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com> wrote:

> >
> >
> >________________________________________
> >From: Andy Shevchenko <andriy.shevchenko@intel.com>
> >Sent: Monday, August 24, 2026 17:32
> >To: Jean-Baptiste Maneyrol
> >Cc: Jonathan Cameron; David Lechner; Nuno Sá; Andy Shevchenko; Jonathan Cameron; linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org; stable@vger.kernel.org
> >Subject: Re: [PATCH] iio: inv_sensors: fix estimated value larger than interrupt timestamp
> >
> >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 >
> >ZjQcmQRYFpfptBannerStart
> >This Message Is From an External Sender
> >This message came from outside your organization.
> >
> >ZjQcmQRYFpfptBannerEnd
> >
> >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?  
> 
> Hello Andy,
> 
> (ts->mult * ts->chip_period.val) is an estimation of the sampling period of
> the chip in ns. It is limited by maximum setting 8kHz (125000) and minimum
> setting 1.5625Hz (640000000), with a 2% margin. Meaning maximum value is
> 652800000, which is below the 32 bits limit.
> 
> ts->chip_period.val is an estimation of the internal frequency which is 8kHz.
> It's value will always be around 125000, with a 2% margin. Maximum value
> being 127500.
> 
> ts->mult will change from 8kHz setting (1) to 1.5625Hz setting (5120).
> 
> Thanks,
> JB
Seems fine to me so applied to the fixes-togreg branch of iio.git

Thanks

Jonathan

> 
> >
> >--
> >With Best Regards,
> >Andy Shevchenko
> >
> >
> >
>