summaryrefslogtreecommitdiff
path: root/lib/efi_loader/efi_device_path_utilities.c
diff options
context:
space:
mode:
authorRasmus Villemoes <ravi@prevas.dk>2025-05-07 12:58:20 +0200
committerStefan Roese <sr@denx.de>2025-05-16 13:44:19 +0200
commit5265143ac7356b94ace3e26a9fd6df17774b189b (patch)
tree828be260a38187ff59cb8bba48b57cf4d1c9df33 /lib/efi_loader/efi_device_path_utilities.c
parent2dbd9101b9910fe2c0fc2c23bc4d13a2604e9cca (diff)
cyclic: make cyclic_register safe to call on already-registered info
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> Reviewed-by: Stefan Roese <sr@denx.de>
Diffstat (limited to 'lib/efi_loader/efi_device_path_utilities.c')
0 files changed, 0 insertions, 0 deletions