linux/kernel/time/alarmtimer.c, branch v6.14

alarmtimer: Switch to use hrtimer_setup() and hrtimer_setup_on_stack()

2024-11-07T01:47:07Z

hrtimer_setup() and hrtimer_setup_on_stack() take the callback function pointer as argument and initialize the timer completely. Replace the hrtimer_init*() variants and the open coded initialization of hrtimer::function with the new setup mechanism. Switch to use the new functions. Signed-off-by: Nam Cao Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/2bae912336103405adcdab96b88d3ea0353b4228.1730386209.git.namcao@linutronix.de

alarmtimers: Remove return value from alarm functions

2024-11-07T01:14:46Z

Now that the SIG_IGN problem is solved in the core code, the alarmtimer callbacks do not require a return value anymore. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Acked-by: Frederic Weisbecker Link: https://lore.kernel.org/all/20241105064214.318837272@linutronix.de

alarmtimers: Remove the throttle mechanism from alarm_forward_now()

2024-11-07T01:14:45Z

Now that ignored posix timer signals are requeued and the timers are rearmed on signal delivery the workaround to keep such timers alive and self rearm them is not longer required. Remove the unused alarm timer parts. Signed-off-by: Thomas Gleixner Reviewed-by: Frederic Weisbecker Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/all/20241105064214.252443020@linutronix.de

posix-timers: Cleanup SIG_IGN workaround leftovers

2024-11-07T01:14:45Z

Now that ignored posix timer signals are requeued and the timers are rearmed on signal delivery the workaround to keep such timers alive and self rearm them is not longer required. Remove the relevant hacks and the not longer required return values from the related functions. The alarm timer workarounds will be cleaned up in a separate step. Signed-off-by: Thomas Gleixner Reviewed-by: Frederic Weisbecker Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/all/20241105064214.187239060@linutronix.de

posix-timers: Add proper state tracking

2024-10-29T10:43:19Z

Right now the state tracking is done by two struct members: - it_active: A boolean which tracks armed/disarmed state - it_signal_seq: A sequence counter which is used to invalidate settings and prevent rearming Replace it_active with it_status and keep properly track about the states in one place. This allows to reuse it_signal_seq to track reprogramming, disarm and delete operations in order to drop signals which are related to the state previous of those operations. Signed-off-by: Thomas Gleixner Reviewed-by: Frederic Weisbecker Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/all/20241001083835.670337048@linutronix.de

posix-timers: Rename k_itimer:: It_requeue_pending

2024-10-29T10:43:19Z

Prepare for using this struct member to do a proper reprogramming and deletion accounting so that stale signals can be dropped. No functional change. Signed-off-by: Thomas Gleixner Reviewed-by: Frederic Weisbecker Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/all/20241001083835.611997737@linutronix.de

treewide: Fix wrong singular form of jiffies in comments

2024-09-08T18:47:40Z

There are several comments all over the place, which uses a wrong singular form of jiffies. Replace 'jiffie' by 'jiffy'. No functional change. Signed-off-by: Anna-Maria Behnsen Signed-off-by: Thomas Gleixner Acked-by: Geert Uytterhoeven # m68k Link: https://lore.kernel.org/all/20240904-devel-anna-maria-b4-timers-flseep-v1-3-e98760256370@linutronix.de

posix-timers: Consolidate signal queueing

2024-07-29T19:57:35Z

Rename posix_timer_event() to posix_timer_queue_signal() as this is what the function is about. Consolidate the requeue pending and deactivation updates into that function as there is no point in doing this in all incarnations of posix timers. Signed-off-by: Thomas Gleixner Signed-off-by: Frederic Weisbecker Acked-by: Peter Zijlstra (Intel)

rtc: class: make rtc_class constant

2024-03-08T11:05:10Z

Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the rtc_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman Suggested-by: Greg Kroah-Hartman Signed-off-by: Ricardo B. Marliere Link: https://lore.kernel.org/r/20240305-class_cleanup-abelloni-v1-1-944c026137c8@marliere.net Signed-off-by: Alexandre Belloni

alarmtimer: Use maximum alarm time for suspend

2023-10-09T13:03:28Z

Some userspace applications use timerfd_create() to request wakeups after a long period of time. For example, a backup application may request a wakeup once per week. This is perfectly fine as long as the system does not try to suspend. However, if the system tries to suspend and the system's RTC does not support the required alarm timeout, the suspend operation will fail with an error such as rtc_cmos 00:01: Alarms can be up to one day in the future PM: dpm_run_callback(): platform_pm_suspend+0x0/0x4a returns -22 alarmtimer alarmtimer.4.auto: platform_pm_suspend+0x0/0x4a returned -22 after 117 usecs PM: Device alarmtimer.4.auto failed to suspend: error -22 This results in a refusal to suspend the system, causing substantial battery drain on affected systems. To fix the problem, use the maximum alarm time offset as reported by RTC drivers to set the maximum alarm time. While this may result in early wakeups from suspend, it is still much better than not suspending at all. Standardize system behavior if the requested alarm timeout is larger than the alarm timeout supported by the rtc chip. Currently, in this situation, the RTC driver will do one of the following: - It may return an error. - It may limit the alarm timeout to the maximum supported by the rtc chip. - It may mask the timeout by the maximum alarm timeout supported by the RTC chip (i.e. a requested timeout of 1 day + 1 minute may result in a 1 minute timeout). With this in place, if the RTC driver reports the maximum alarm timeout supported by the RTC chip, the system will always limit the alarm timeout to the maximum supported by the RTC chip. Signed-off-by: Guenter Roeck Signed-off-by: Thomas Gleixner Acked-by: John Stultz Link: https://lore.kernel.org/r/20230915152238.1144706-3-linux@roeck-us.net