aboutsummaryrefslogtreecommitdiff
path: root/include/asm-generic
diff options
context:
space:
mode:
authorSean Anderson <seanga2@gmail.com>2020-09-09 16:24:56 -0400
committerTom Rini <trini@konsulko.com>2020-10-14 11:16:34 -0400
commit4b2be78ab66ca3f6f177823c0f81fcdd1d476e9b (patch)
treeff001912d290302e353749f11784ef6bff4cd997 /include/asm-generic
parentd74fcee2d8b41ec809ef42e279b60190673897f4 (diff)
downloadu-boot-4b2be78ab66ca3f6f177823c0f81fcdd1d476e9b.zip
u-boot-4b2be78ab66ca3f6f177823c0f81fcdd1d476e9b.tar.gz
u-boot-4b2be78ab66ca3f6f177823c0f81fcdd1d476e9b.tar.bz2
time: Fix get_ticks being non-monotonic
get_ticks does not always succeed. Sometimes it can be called before the timer has been initialized. If it does, it returns a negative errno. This causes the timer to appear non-monotonic, because the value will become much smaller after the timer is initialized. No users of get_ticks which I checked handle errors of this kind. Further, functions like tick_to_time mangle the result of get_ticks, making it very unlikely that one could check for an error without suggesting a patch such as this one. This patch panics if we ever get an error. There are two cases in which this can occur. The first is if we couldn't find/probe the timer for some reason. One reason for this is if the timer is not available so early. This likely indicates misconfiguration. Another reason is that the timer has an invalid/missing device tree binding. In this case, panicing is also correct. The second case covers errors calling get_count. This can only occur if the timer is missing a get_count function (or on RISC-V, but that should be fixed soon). Fixes: c8a7ba9e6a5 Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Diffstat (limited to 'include/asm-generic')
0 files changed, 0 insertions, 0 deletions