linux-toradex.git/kernel/time/alarmtimer.c, branch v5.9-rc6

time: Delete repeated words in comments

2020-08-10T20:14:07+00:00

Drop repeated words in kernel/time/.  {when, one, into}

Signed-off-by: Randy Dunlap 
Signed-off-by: Thomas Gleixner 
Acked-by: John Stultz 
Link: https://lore.kernel.org/r/20200807033248.8452-1-rdunlap@infradead.org

alarmtimer: Make alarmtimer_get_rtcdev() a stub when CONFIG_RTC_CLASS=n

2020-01-24T20:03:53+00:00

The stubbed version of alarmtimer_get_rtcdev() is not exported.
so this won't work if this function is used in a module when
CONFIG_RTC_CLASS=n.

Move the stub function to the header file and make it inline so that
callers don't have to worry about linking against this symbol.

rtcdev isn't used outside of this ifdef so it's not required to be
redefined to NULL. Drop that while touching this area.

Signed-off-by: Stephen Boyd 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20200124055849.154411-4-swboyd@chromium.org

alarmtimer: Use wakeup source from alarmtimer platform device

2020-01-24T20:00:21+00:00

Use the wakeup source that can be associated with the 'alarmtimer'
platform device instead of registering another one by hand.

Signed-off-by: Stephen Boyd 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Douglas Anderson 
Link: https://lore.kernel.org/r/20200124055849.154411-3-swboyd@chromium.org

alarmtimer: Make alarmtimer platform device child of RTC device

2020-01-24T20:00:20+00:00

The alarmtimer_suspend() function will fail if an RTC device is on a bus
such as SPI or i2c and that RTC device registers and probes after
alarmtimer_init() registers and probes the 'alarmtimer' platform device.

This is because system wide suspend suspends devices in the reverse order
of their probe. When alarmtimer_suspend() attempts to program the RTC for a
wakeup it will try to program an RTC device on a bus that has already been
suspended.

Move the alarmtimer device registration to happen when the RTC which is
used for wakeup is registered. Register the 'alarmtimer' platform device as
a child of the RTC device too, so that it can be guaranteed that the RTC
device won't be suspended when alarmtimer_suspend() is called.

Reported-by: Douglas Anderson 
Signed-off-by: Stephen Boyd 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Douglas Anderson 
Link: https://lore.kernel.org/r/20200124055849.154411-2-swboyd@chromium.org

alarmtimer: Update alarmtimer_get_rtcdev() docs to reflect reality

2020-01-24T20:00:20+00:00

This function doesn't do anything like this comment says when an RTC device
hasn't been chosen. It looks like we used to do something like that before
commit 8bc0dafb5cf3 ("alarmtimers: Rework RTC device selection using class
interface") but that's long gone now. Remove this sentence to avoid
confusing the reader.

Signed-off-by: Stephen Boyd 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20200124055849.154411-5-swboyd@chromium.org

alarmtimer: Unregister wakeup source when module get fails

2020-01-15T10:16:54+00:00

The alarmtimer_rtc_add_device() function creates a wakeup source and then
tries to grab a module reference. If that fails the function returns early
with an error code, but fails to remove the wakeup source.

Cleanup this exit path so there is no dangling wakeup source, which is
named 'alarmtime' left allocated which will conflict with another RTC
device that may be registered later.

Fixes: 51218298a25e ("alarmtimer: Ensure RTC module is not unloaded")
Signed-off-by: Stephen Boyd 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Douglas Anderson 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200109155910.907-2-swboyd@chromium.org

alarmtimer: Make nanosleep() time namespace aware

2020-01-14T11:20:55+00:00

clock_nanosleep() accepts absolute values of expiration time when the
TIMER_ABSTIME flag is set. This absolute value is inside the task's
time namespace and has to be converted to the host's time.

Co-developed-by: Dmitry Safonov 
Signed-off-by: Andrei Vagin 
Signed-off-by: Dmitry Safonov 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20191112012724.250792-16-dima@arista.com

posix-clocks: Wire up clock_gettime() with timens offsets

2020-01-14T11:20:52+00:00

Adjust monotonic and boottime clocks with per-timens offsets.  As the
result a process inside time namespace will see timers and clocks corrected
to offsets that were set when the namespace was created

Note that applications usually go through vDSO to get time, which is not
yet adjusted. Further changes will complete time namespace virtualisation
with vDSO support.

Co-developed-by: Dmitry Safonov 
Signed-off-by: Andrei Vagin 
Signed-off-by: Dmitry Safonov 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20191112012724.250792-12-dima@arista.com

posix-clocks: Introduce clock_get_ktime() callback

2020-01-14T11:20:51+00:00

The callsite in common_timer_get() has already a comment:
    /*
     * The timespec64 based conversion is suboptimal, but it's not
     * worth to implement yet another callback.
     */
    kc->clock_get(timr->it_clock, &ts64);
    now = timespec64_to_ktime(ts64);

The upcoming support for time namespaces requires to have access to:

 - The time in a task's time namespace for sys_clock_gettime()
 - The time in the root name space for common_timer_get()

That adds a valid reason to finally implement a separate callback which
returns the time in ktime_t format.

Suggested-by: Thomas Gleixner 
Co-developed-by: Dmitry Safonov 
Signed-off-by: Andrei Vagin 
Signed-off-by: Dmitry Safonov 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20191112012724.250792-10-dima@arista.com

alarmtimer: Provide get_timespec() callback

2020-01-14T11:20:51+00:00

The upcoming support for time namespaces requires to have access to:

  - The time in a task's time namespace for sys_clock_gettime()
  - The time in the root name space for common_timer_get()

Wire up alarm bases with get_timespec().

Suggested-by: Thomas Gleixner 
Co-developed-by: Dmitry Safonov 
Signed-off-by: Andrei Vagin 
Signed-off-by: Dmitry Safonov 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20191112012724.250792-9-dima@arista.com