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

[Jean-Baptiste Maneyrol]

>
>
>________________________________________
>From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>
>Sent: Monday, August 24, 2026 17:32
>To: Jean-Baptiste Maneyrol
>Cc: Jonathan Cameron; David Lechner; Nuno Sá; Andy Shevchenko; Jonathan Cameron; linux-iio@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx
>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
>
>
>
>