From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 14 Oct 2020 13:42:25 -0400 Subject: [PATCH v2] time: Fix get_ticks being non-monotonic In-Reply-To: <20200909202456.233249-1-seanga2@gmail.com> References: <20200909202456.233249-1-seanga2@gmail.com> Message-ID: <20201014174225.GB14816@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Sep 09, 2020 at 04:24:56PM -0400, 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 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 > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: