When CONFIG_TIMEOUT_64BIT is y, positive values are relative/delta
timeouts and negative values are absolute timeouts, except
for two special values. -1 is K_WAIT_FOREVER and 0 is K_NO_WAIT.
The reserved value of -1 means INT64_MAX is not a valid argument
to K_TIMEOUT_ABS_TICKS(), but there was no check. If a literal
was passed, a preprocessor/compiler warning would be generated
for overflow, but if a variable was passed as the argument,
then the code would compile but not work correctly since the
absolute timeout would be changed to a relative one. One
example of this is task_wdt_init() if no channels are enabled.
Rather than just fixing task_wdt, and trying to find other cases
in an adhoc way, this CL changes K_TIMEOUT_ABS_TICKS() to
limit the larges value to (INT64_MAX-1). It does so silently,
but given the range of int64_t, there should be no practical
difference.
Also, change the implementation for Z_IS_TIMEOUT_RELATIVE() to
fix the case where INT64_MAX relative timeout was being
improperly reported as being not a relative timeout. This was
again due to the -1 reserved value.
Add some tests for these changes to the timer_api test.
Signed-off-by: Mike J. Chen <mjchen@google.com>
9075d53355