From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Anderson Date: Sun, 6 Sep 2020 22:02:20 -0400 Subject: [PATCH] time: Fix get_ticks being non-monotonic In-Reply-To: References: <20200901195548.542737-1-seanga2@gmail.com> Message-ID: <5496c4c8-4ed2-dc25-820b-c09a36d93b5e@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 9/6/20 9:43 PM, Simon Glass wrote: > Hi Sean, > > On Tue, 1 Sep 2020 at 13:56, Sean Anderson wrote: >> >> 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 changes get_ticks to always return 0 when there is an error. >> 0 is the least unsigned integer, ensuring get_ticks appears monotonic. This >> has the side effect of time apparently not passing until the timer is >> initialized. However, without this patch, time does not pass anyway, >> because the error value is likely to be the same. >> >> Fixes: c8a7ba9e6a5 >> Signed-off-by: Sean Anderson >> --- >> >> lib/time.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) > > Would it be better to panic so people can fix the bug? I thought this was expected behavior. It's only a bug if you do something like udelay before any timers are created. We just can't report errors through get_ticks, because its users assume that it always returns a time of some kind. --Sean