[PATCH 2/3] cyclic: make cyclic_register safe to call on already-registered info

[Rasmus Villemoes <ravi@prevas.dk>]

Now that cyclic_unregister() is safe to call on a not-registered
cyclic_info, we can make cyclic_register() behave like the mod_timer()
and hrtimer_start() APIs in linux, in that they don't distinguish
between whether the timer was already enabled or not; from the point
of the call it is, with whatever timeout/period is set in that most
recent call.

This avoids users of the cyclic API from separately keeping track of
whether their callback is already registered or not, and even if they
know it is, can be used for changing the period (and/or the callback
function) without first doing unregister().

See also this recent'ish message from kernel maintainer Thomas
Gleixner on that API design for timer frameworks:

  https://lore.kernel.org/lkml/87ikn6sibi.ffs@tglx/

  First of all the question is whether add() and mod() are really
  valuable distinctions. I'm not convinced at all. Back then, when we
  introduced hrtimers, we came to the conclusion that hrtimer_start()
  is sufficient.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
---
 common/cyclic.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/common/cyclic.c b/common/cyclic.c
index 75662d9f613..ec952a01ee1 100644
--- a/common/cyclic.c
+++ b/common/cyclic.c
@@ -43,6 +43,8 @@ static bool cyclic_is_registered(const struct cyclic_info *cyclic)
 void cyclic_register(struct cyclic_info *cyclic, cyclic_func_t func,
 		     uint64_t delay_us, const char *name)
 {
+	cyclic_unregister(cyclic);
+
 	memset(cyclic, 0, sizeof(*cyclic));
 
 	/* Store values in struct */
-- 
2.49.0