drivers: timer: stm32 lptim fix Potentially overflow

[FRASTM]

Fix Unintentional integer overflow in the calculation
Integer handling issues (OVERFLOW_BEFORE_WIDEN)
Potentially overflowing expression with a cast

Fixes #29700
Fixes #29697

Signed-off-by: Francois Ramu [email protected]

[r2r0]

Is there a reason why these calculations are done in two different ways (multiplication then division and division then multiplication)?
If we want to have the same results with the same inputs (and do not loose precision) then multiplication should be performed first using 64 bits arithmetic (casting) and then there should be made a division.

[FRASTM]

with this calculation on 64bit of returned time value, the timer tests can pass on nucleo_wb55rg
tests/kernel/timer/timer_monotonic/
tests/kernel/timer/timer_api

[aurel32]

This doesn't look correct to me, but it was already the case before and not due to to you change. If the computation has to be done with precision as in the comment, it should be:
uint64_t ret = ((uint64_t)lp_time * sys_clock_hw_cycles_per_sec()) / LPTIM_CLOCK;

Basically just like the other change. Also note that sys_clock_hw_cycles_per_sec is equivalent to CONFIG_SYS_CLOCK_TICKS_PER_SEC when CONFIG_TIMER_READS_ITS_FREQUENCY_AT_RUNTIME is not defined, which is the case for this driver.

[FRASTM]

Ok,
I did not find any error when testing (10x) tests/kernel/timer/timer_api and tests/kernel/timer/timer_monotonic on nucleo stm32wb55 (when lptim enabled)

[r2r0]

As me and @aurel32 already wrote, dividing before multiplying causes lost of precision.
I.e. consider: sys_clock_hw_cycles_per_sec() = 64000000, LPTIM_CLOCK=32768, lp_time=32768 - the correct result is 64000000, but actual code gives: 63995904
Consider using expression as below, please.

uint64_t ret = ((uint64_t)lp_time * sys_clock_hw_cycles_per_sec()) / LPTIM_CLOCK;

[r2r0]

Thanks @FRASTM

[aurel32]

Thanks for the fix, it looks good to me now.