Provide a -r option to display when fragments contain redundant
options. This is really useful when breaking apart a config into
fragments, as well as cleaning up older fragments.
Signed-off-by: John Stultz <[email protected]>
Acked-by: Darren Hart <[email protected]>
Acked-by: Bruce Ashfield <[email protected]>
Signed-off-by: Michal Marek <[email protected]>
Somehow the merge_config.sh script didn't get its execute bit
set when it was merged. Fix this.
Signed-off-by: John Stultz <[email protected]>
Acked-by: Darren Hart <[email protected]>
Acked-by: Bruce Ashfield <[email protected]>
Signed-off-by: Michal Marek <[email protected]>
Folks have been getting a number of warnings about time
adjustments > 11%. The WARN_ON leaves a big useless backtrace
so this patch removes it for a printk_once().
I'm still working to narrow down the cause of the > 11% adjustment.
Signed-off-by: John Stultz <[email protected]>
jonghwan Choi reported seeing warnings with the alarmtimer
code at suspend/resume time, and pointed out that the
rtctimer isn't being properly initialized.
This patch corrects this issue.
Reported-by: jonghwan Choi <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Since commit 7dffa3c673 the ntp
subsystem has used an hrtimer for triggering the leapsecond
adjustment. However, this can cause a potential livelock.
Thomas diagnosed this as the following pattern:
CPU 0 CPU 1
do_adjtimex()
spin_lock_irq(&ntp_lock);
process_adjtimex_modes(); timer_interrupt()
process_adj_status(); do_timer()
ntp_start_leap_timer(); write_lock(&xtime_lock);
hrtimer_start(); update_wall_time();
hrtimer_reprogram(); ntp_tick_length()
tick_program_event() spin_lock(&ntp_lock);
clockevents_program_event()
ktime_get()
seq = req_seqbegin(xtime_lock);
This patch tries to avoid the problem by reverting back to not using
an hrtimer to inject leapseconds, and instead we handle the leapsecond
processing in the second_overflow() function.
The downside to this change is that on systems that support highres
timers, the leap second processing will occur on a HZ tick boundary,
(ie: ~1-10ms, depending on HZ) after the leap second instead of
possibly sooner (~34us in my tests w/ x86_64 lapic).
This patch applies on top of tip/timers/core.
CC: Sasha Levin <[email protected]>
CC: Thomas Gleixner <[email protected]>
Reported-by: Sasha Levin <[email protected]>
Diagnoised-by: Thomas Gleixner <[email protected]>
Tested-by: Sasha Levin <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Richard Weinberger noticed that on some RTC hardware that
doesn't support UIE mode, due to coarse granular alarms
(like 1minute resolution), the current virtualized RTC
support doesn't properly error out when UIE is enabled.
Instead the current code queues an alarm for the next second,
but it won't fire until up to a miniute later.
This patch provides a generic way to flag this sort of hardware
and fixes the issue on the mpc5121 where Richard noticed the
problem.
CC: [email protected]
Reported-by: Richard Weinberger <[email protected]>
Tested-by: Richard Weinberger <[email protected]>
Signed-off-by: John Stultz <[email protected]>
change_clocksource() fails to grab locks or call timekeeping_update(),
which leaves a race window for time inconsistencies.
This adds proper locking and a call to timekeeping_update() to fix this.
CC: Andy Lutomirski <[email protected]>
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
When switching from a vsyscall capable to a non-vsyscall capable
clocksource, there was a small race, where the last vsyscall
gettimeofday before the switch might return a invalid time value
using the new non-vsyscall enabled clocksource values after the
switch is complete.
This is due to the vsyscall code checking the vclock_mode once
outside of the seqcount protected section. After it reads the
vclock mode, it doesn't re-check that the sampled clock data
that is obtained in the seqcount critical section still matches.
The fix is to sample vclock_mode inside the protected section,
and as long as it isn't VCLOCK_NONE, return the calculated
value. If it has changed and is now VCLOCK_NONE, fall back
to the syscall gettime calculation.
v2:
* Cleanup checks as suggested by tglx
* Also fix same issue present in gettimeofday path
CC: Andy Lutomirski <[email protected]>
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Older out of tree drivers that were desgined to the Android Alarm
in-kernel API may not build due to the namespace collision fixed in
an earlier patch. Per Arve's suggestion, this patch provides
preprocessor macros that allow older drivers to build.
CC: Arve Hjønnevåg <[email protected]>
CC: Android Kernel Team <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
This patch fixes the following warnings:
drivers/staging/android/alarm.c: In function ‘alarm_timer_triggered’:
drivers/staging/android/alarm.c:344: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘long int’
drivers/staging/android/alarm.c:367: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘long int’
CC: Arve Hjønnevåg <[email protected]>
CC: Android Kernel Team <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The upstreamed alarmtimers are similar but not quite 100% API
compatibile with the android in-kernel alarm api. To aid the
transition, prefix the the android in-kernel api with android_
CC: Arve Hjønnevåg <[email protected]>
CC: Android Kernel Team <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The file asm/mach/time.h doesn't exist on all arches,
so include <linux/time.h>. Also linux/sysdev.h is gone
so kill it.
CC: Arve Hjønnevåg <[email protected]>
CC: Android Kernel Team <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
As noted by Arve and others, since wall time can jump backwards, it is
difficult to use for input because one cannot determine if one event
occurred before another or for how long a key was pressed.
However, the timestamp field is part of the kernel ABI, and cannot be
changed without possibly breaking existing users.
This patch adds a new IOCTL that allows a clockid to be set in the
evdev_client struct that will specify which time base to use for event
timestamps (ie: CLOCK_MONOTONIC instead of CLOCK_REALTIME).
For now we only support CLOCK_MONOTONIC and CLOCK_REALTIME, but
in the future we could support other clockids if appropriate.
The default remains CLOCK_REALTIME, so we don't change the ABI.
Signed-off-by: John Stultz <[email protected]>
Reviewed-by: Daniel Kurtz <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Now that ntp.c's locking is reworked, we can remove most
of the xtime_lock usage in timekeeping.c
The remaining xtime_lock presence is really for jiffies access
and the global load calculation.
CC: Thomas Gleixner <[email protected]>
CC: Eric Dumazet <[email protected]>
CC: Richard Cochran <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Currently the NTP managed tick_length value is accessed globally,
in preparations for locking cleanups, make sure it is accessed via
a function and mark it as static.
CC: Thomas Gleixner <[email protected]>
CC: Eric Dumazet <[email protected]>
CC: Richard Cochran <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Move ntp_sycned to ntp.c and mark time_status as static.
Also yank function declaration for non-existant function.
CC: Thomas Gleixner <[email protected]>
CC: Eric Dumazet <[email protected]>
CC: Richard Cochran <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Now that all the timekeeping variables are stored in
the timekeeper structure, add a new lock to protect the
structure.
For now, this lock nests under the xtime_lock for writes.
For readers, we don't need to take xtime_lock anymore.
CC: Thomas Gleixner <[email protected]>
CC: Eric Dumazet <[email protected]>
CC: Richard Cochran <[email protected]>
Signed-off-by: John Stultz <[email protected]>
In some cases at boot up, the RTC alarm may be set in the past,
but still have the enabled flag on. This was causing problems,
because we would then enqueue the alarm into the timerqueue,
but it would never fire. This would clog up the timerqueue
and keep other alarms from working.
The fix is to check the alarm against the current rtc time at
boot and avoid enqueueing the alarm if it is in the past.
Reported-by: NeilBrown <[email protected]>
Tested-by: NeilBrown <[email protected]>
Tested-by: Sander Eikelenboom <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Arnaud Lacombe pointed out the final checking that the requested configs
were included in the final .config was broken.
The example was that if you had a fragment that disabled
CONFIG_DECOMPRESS_GZIP applied to a normal defconfig, there would be no
final warning that CONFIG_DECOMPRESS_GZIP was acutally set in the final
.config.
This bug was introduced by me in v3 of the original patch, and the
following patch reverts the invalid change.
Signed-off-by: John Stultz <[email protected]>
Reported-by: Arnaud Lacombe <[email protected]>
Cc: Darren Hart <[email protected]>
Cc: Michal Marek <[email protected]>
Cc: Arnaud Lacombe <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Michal Marek <[email protected]>
The m41t80 driver can read and set the alarm, but it doesn't
seem to have a functional alarm irq.
This causes failures when the generic core sees alarm functions,
but then cannot use them properly for things like UIE mode.
Disabling the alarm functions allows proper error reporting,
and possible fallback to emulated modes. Once someone fixes
the alarm irq functionality, this can be restored.
CC: [email protected]
CC: Matt Turner <[email protected]>
CC: Nico Macrionitis <[email protected]>
CC: Atsushi Nemoto <[email protected]>
Reported-by: Matt Turner <[email protected]>
Reported-by: Nico Macrionitis <[email protected]>
Tested-by: Nico Macrionitis <[email protected]>
Signed-off-by: John Stultz <[email protected]>
For some frequencies, the clocks_calc_mult_shift() function will
unfortunately select mult values very close to 0xffffffff. This
has the potential to overflow when NTP adjusts the clock, adding
to the mult value.
This patch adds a clocksource.maxadj value, which provides
an approximation of an 11% adjustment(NTP limits adjustments to
500ppm and the tick adjustment is limited to 10%), which could
be made to the clocksource.mult value. This is then used to both
check that the current mult value won't overflow/underflow, as
well as warning us if the timekeeping_adjust() code pushes over
that 11% boundary.
v2: Fix max_adjustment calculation, and improve WARN_ONCE
messages.
v3: Don't warn before maxadj has actually been set
CC: Yong Zhang <[email protected]>
CC: David Daney <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: Chen Jie <[email protected]>
CC: zhangfx <[email protected]>
CC: [email protected]
Reported-by: Chen Jie <[email protected]>
Reported-by: zhangfx <[email protected]>
Tested-by: Yong Zhang <[email protected]>
Signed-off-by: John Stultz <[email protected]>
After getting a number of questions in private emails about the
math around admittedly very complex timekeeping_adjust() and
timekeeping_big_adjust(), I figure the code needs some better
comments.
Hopefully the explanations are clear enough and don't muddy the
water any worse.
Still needs documentation for ntp_error, but I couldn't recall
exactly the full explanation behind the code that's there
(although I do recall once working it out when Roman first
proposed it). Given a bit more time I can probably work it out,
but I don't want to hold back this documentation until then.
Signed-off-by: John Stultz <[email protected]>
Cc: Chen Jie <[email protected]>
Cc: Steven Rostedt <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Awhile back I removed all the CONFIG_GENERIC_TIME referecnes as
the last of the non-GENERIC_TIME arches were converted.
However, due to the functionality being important and around for
awhile, there apparently were some out of tree hardware enablement
patches that used it and have since been merged.
This patch removes the remaining instances of GENERIC_TIME.
Singed-off-by: John Stultz <[email protected]>
an 'unhandled fault' is causes when a gadget driver calls
usb_gadget_connect() while the USB cable isn't plugged into
the OTG port.
the fault is caused by an access to MUSB's memory space
while its clock is turned off due to pm_runtime kicking
in.
in order to fix the fault, we enclose musb_gadget_pullup()
with pm_runtime_get_sync() ... pm_runtime_put() calls to
be sure we will always reach that path with clock turned on.
[ [email protected] : simplified commit log; removed few things
which didn't belong there ]
Cc: [email protected]
Reported-by: Zach Pfeffer <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Thomas earlier submitted a fix to limit the RTC PIE freq, but
picked 5000Hz out of the air. Willy noticed that we should
instead use the 8192Hz max from the rtc man documentation.
Cc: Willy Tarreau <[email protected]>
Cc: [email protected]
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
This allows cleaner detection of the RTC device being registered, rather
then probing any time someone calls alarmtimer_get_rtcdev.
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
There's a number of edge cases when cancelling a alarm, so
to be sure we accurately do so, introduce try_to_cancel, which
returns proper failure errors if it cannot. Also modify cancel
to spin until the alarm is properly disabled.
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
In order to allow for functionality like try_to_cancel, add
more refined state tracking (similar to hrtimers).
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Now that periodic alarmtimers are managed by the handler function,
remove the period value from the alarm structure and let the handlers
manage the interval on their own.
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Now that the alarmtimers code has been refactored, the interval
cap limit can be removed.
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
In order to avoid wasting time expiring and re-adding very high freq
periodic alarmtimers, introduce alarm_forward() which is similar to
hrtimer_forward and moves the timer to the next future expiration time
and returns the number of overruns.
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
This patch pushes the periodic alarmtimer re-arming down into the alarmtimer
handler, mimicking how hrtimers handle this.
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
In order to properly fix the denial of service issue with high freq
periodic alarm timers, we need to push the re-arming logic into the
alarm timer handler, much as the hrtimer code does.
This patch introduces alarmtimer_restart enum and changes the
alarmtimer handler declarations to use it as a return value. Further,
to ease following changes, it extends the alarmtimer handler functions
to also take the time at expiration. No logic is yet modified.
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Its possible to jam up the alarm timers by setting very small interval
timers, which will cause the alarmtimer subsystem to spend all of its time
firing and restarting timers. This can effectivly lock up a box.
A deeper fix is needed, closely mimicking the hrtimer code, but for now
just cap the interval to 100us to avoid userland hanging the system.
CC: Thomas Gleixner <[email protected]>
CC: [email protected]
Signed-off-by: John Stultz <[email protected]>
an 'unhandled fault' is causes when a gadget driver calls
usb_gadget_connect() while the USB cable isn't plugged into
the OTG port.
the fault is caused by an access to MUSB's memory space
while its clock is turned off due to pm_runtime kicking
in.
in order to fix the fault, we enclose musb_gadget_pullup()
with pm_runtime_get_sync() ... pm_runtime_put() calls to
be sure we will always reach that path with clock turned on.
[ [email protected] : simplified commit log; removed few things
which didn't belong there ]
Cc: [email protected]
Reported-by: Zach Pfeffer <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Terribly embarassing. Don't know how I committed this, but its
KERN_WARNING not KERN_WARN.
This fixes the following compile error:
kernel/time/timekeeping.c: In function ‘__timekeeping_inject_sleeptime’:
kernel/time/timekeeping.c:608: error: ‘KERN_WARN’ undeclared (first use in this function)
kernel/time/timekeeping.c:608: error: (Each undeclared identifier is reported only once
kernel/time/timekeeping.c:608: error: for each function it appears in.)
kernel/time/timekeeping.c:608: error: expected ‘)’ before string constant
make[2]: *** [kernel/time/timekeeping.o] Error 1
Reported-by: Ingo Molnar <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Because the RTC interface is only a second granular interface,
each time we read from the RTC for suspend/resume, we introduce a
half second (on average) of error.
In order to avoid this error accumulating as the system is suspended
over and over, this patch measures the time delta between the RTC
and the system CLOCK_REALTIME.
If the delta is less then 2 seconds from the last suspend, we compensate
by using the previous time delta (keeping it close). If it is larger
then 2 seconds, we assume the clock was set or has been changed, so we
do no correction and update the delta.
Note: If NTP is running, ths could seem to "fight" with the NTP corrected
time, where as if the system time was off by 1 second, and NTP slewed the
value in, a suspend/resume cycle could undo this correction, by trying to
restore the previous offset from the RTC. However, without this patch,
since each read could cause almost a full second worth of error, its
possible to get almost 2 seconds of error just from the suspend/resume
cycle alone, so this about equal to any offset added by the compensation.
Further on systems that suspend/resume frequently, this should keep time
closer then NTP could compensate for if the errors were allowed to
accumulate.
Credits to Arve Hjønnevåg for suggesting this solution.
This patch also improves some of the variable names and adds more clear
comments.
CC: Arve Hjønnevåg <[email protected]>
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Because the read_persistent_clock interface is usually backed by
only a second granular interface, each time we read from the persistent
clock for suspend/resume, we introduce a half second (on average) of error.
In order to avoid this error accumulating as the system is suspended
over and over, this patch measures the time delta between the persistent
clock and the system CLOCK_REALTIME.
If the delta is less then 2 seconds from the last suspend, we compensate
by using the previous time delta (keeping it close). If it is larger
then 2 seconds, we assume the clock was set or has been changed, so we
do no correction and update the delta.
Note: If NTP is running, ths could seem to "fight" with the NTP corrected
time, where as if the system time was off by 1 second, and NTP slewed the
value in, a suspend/resume cycle could undo this correction, by trying to
restore the previous offset from the persistent clock. However, without
this patch, since each read could cause almost a full second worth of
error, its possible to get almost 2 seconds of error just from the
suspend/resume cycle alone, so this about equal to any offset added by
the compensation.
Further on systems that suspend/resume frequently, this should keep time
closer then NTP could compensate for if the errors were allowed to
accumulate.
Credits to Arve Hjønnevåg for suggesting this solution.
CC: Arve Hjønnevåg <[email protected]>
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Arve suggested making sure we catch possible negative sleep time
intervals that could be passed into timekeeping_inject_sleeptime.
CC: Arve Hjønnevåg <[email protected]>
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Toralf Förster and Richard Weinberger noted that if there is
no RTC device, the alarm timers core prints out an annoying
"ALARM timers will not wake from suspend" message.
This warning has been removed in a previous patch, however
the issue still remains: The original idea was to support
alarm timers even if there was no rtc device, as long as the
system didn't go into suspend.
However, after further consideration, communicating to the application
that alarmtimers are not fully functional seems like the better
solution.
So this patch makes it so we return -ENOTSUPP to any posix _ALARM
clockid calls if there is no backing RTC device on the system.
Further this changes the behavior where when there is no rtc device
we will check for one on clock_getres, clock_gettime, timer_create,
and timer_nsleep instead of on suspend.
CC: Toralf Förster <[email protected]>
CC: Richard Weinberger <[email protected]
CC: Peter Zijlstra <[email protected]>
CC: Thomas Gleixner <[email protected]>
Reported-by: Toralf Förster <[email protected]>
Reported by: Richard Weinberger <[email protected]>
Signed-off-by: John Stultz <[email protected]>
The alarmtimers code currently picks a rtc device to use at
late init time. However, if your rtc driver is loaded as a module,
it may be registered after the alarmtimers late init code, leaving
the alarmtimers nonfunctional.
This patch moves the the rtcdevice selection to when we actually try
to use it, allowing us to make use of rtc modules that may have been
loaded at any point since bootup.
CC: Thomas Gleixner <[email protected]>
CC: Meelis Roos <[email protected]>
Reported-by: Meelis Roos <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Bryan Henderson noticed that the "RTC: Fix rtc driver ioctl specific
shortcutting" commit has a small bug: When an ioctl is called with an
invalid command code and the clock driver does not have an "ioctl"
method, the ioctl returns rc 0 instead of -ENOTTY.
This patch fixes the issue.
CC: Bryan Henderson <[email protected]>
CC: Gabor Z. Papp <[email protected]>
Reported-by: Bryan Henderson <[email protected]>
Signed-off-by: John Stultz <[email protected]>
If the dp83640 driver is not built as a module, the
MODULE_DEVICE_TABLE reference to dp83640_tbl nops out.
Since the table isn't referenced elsewhere, it it causes
the following warning:
drivers/net/phy/dp83640.c:1095: warning: ‘dp83640_tbl’ defined but not used
This apparently is common with mdio_device_id table structures,
and is avoided by using __maybe_unused annotation.
Signed-off-by: John Stultz <[email protected]>
In 2008 Masashi YOKOTA <[email protected]> created the virtual
battery driver found here:
http://downloads.pylone.jp/src/virtual_battery/virtual_battery-0.0.1.tar.bz2
It found use out of tree, but was never merged upstream.
Since then the test_power driver has been merged, which provides
very similar functionality.
This patch extends the test_power driver to be more dynamic
at runtime, by merging portions of the Virtual Battery Driver
by Masashi YOKOTA.
With this patch, I can tweak the values in:
/sys/module/test_power/parameters/* and watch the behavior of
the gnome power managment daemon or other battery UI software.
CC: Anton Vorontsov <[email protected]>
CC: Akihiro MAEDA <[email protected]>
CC: Masashi YOKOTA <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Anton Vorontsov <[email protected]>
Commit f44f7f96a2 ("RTC: Initialize kernel state from RTC") uncovered
an issue in a number of RTC drivers, where the drivers call
rtc_device_register before initializing the device or platform drvdata.
This frequently results in null pointer dereferences when the
rtc_device_register immediately makes use of the rtc device, calling
rtc_read_alarm.
The solution is to ensure the drvdata is initialized prior to registering
the rtc device.
CC: Wolfram Sang <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: [email protected]
Signed-off-by: John Stultz <[email protected]>
Commit f44f7f96a2 ("RTC: Initialize kernel state from RTC") uncovered
an issue in a number of RTC drivers, where the drivers call
rtc_device_register before initializing the device or platform drvdata.
This frequently results in null pointer dereferences when the
rtc_device_register immediately makes use of the rtc device, calling
rtc_read_alarm.
The solution is to ensure the drvdata is initialized prior to registering
the rtc device.
CC: Wolfram Sang <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: [email protected]
Signed-off-by: John Stultz <[email protected]>
Commit f44f7f96a2 ("RTC: Initialize kernel state from RTC") uncovered
an issue in a number of RTC drivers, where the drivers call
rtc_device_register before initializing the device or platform drvdata.
This frequently results in null pointer dereferences when the
rtc_device_register immediately makes use of the rtc device, calling
rtc_read_alarm.
The solution is to ensure the drvdata is initialized prior to registering
the rtc device.
CC: Wolfram Sang <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: [email protected]
Signed-off-by: John Stultz <[email protected]>
Commit f44f7f96a2 ("RTC: Initialize kernel state from RTC") uncovered
an issue in a number of RTC drivers, where the drivers call
rtc_device_register before initializing the device or platform drvdata.
This frequently results in null pointer dereferences when the
rtc_device_register immediately makes use of the rtc device, calling
rtc_read_alarm.
The solution is to ensure the drvdata is initialized prior to registering
the rtc device.
CC: Wolfram Sang <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: [email protected]
Signed-off-by: John Stultz <[email protected]>
Commit f44f7f96a2 ("RTC: Initialize kernel state from RTC") uncovered
an issue in a number of RTC drivers, where the drivers call
rtc_device_register before initializing the device or platform drvdata.
This frequently results in null pointer dereferences when the
rtc_device_register immediately makes use of the rtc device, calling
rtc_read_alarm.
The solution is to ensure the drvdata is initialized prior to registering
the rtc device.
CC: Wolfram Sang <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: [email protected]
Signed-off-by: John Stultz <[email protected]>
Commit f44f7f96a2 ("RTC: Initialize kernel state from RTC") uncovered
an issue in a number of RTC drivers, where the drivers call
rtc_device_register before initializing the clientdata.
This frequently results in null pointer dereferences when the
rtc_device_register immediately makes use of the rtc device, calling
rtc_read_alarm.
The solution is to ensure the clientdata is initialized prior to registering
the rtc device.
CC: Wolfram Sang <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: [email protected]
Signed-off-by: John Stultz <[email protected]>
Commit f44f7f96a2 ("RTC: Initialize kernel state from RTC") uncovered
an issue in a number of RTC drivers, where the drivers call
rtc_device_register before initializing the device or platform drvdata.
This frequently results in null pointer dereferences when the
rtc_device_register immediately makes use of the rtc device, calling
rtc_read_alarm.
The solution is to ensure the drvdata is initialized prior to registering
the rtc device.
CC: Wolfram Sang <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: [email protected]
Signed-off-by: John Stultz <[email protected]>
The RTC subsystem has a number of accessors that are available via
include/linux/rtc.h. However many of these interfaces are not
available for use if CONFIG_RTC_CLASS=m.
So in order to support wider use of the RTC in the kernel, I'm
removing the tristate config option for a bool, so that code can
easily be conditionalized if the RTC class is present or not.
Signed-off-by: John Stultz <[email protected]>
Cc: Ingo Molnar <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Ingo pointed out that the alarmtimers won't build if CONFIG_RTC_CLASS=n.
This patch adds proper ifdefs to the alarmtimer code to disable the rtc
usage if it is not built in.
Reported-by: Ingo Molnar <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Thomas asked about the delayed irq work in the alarmtimers code,
and I realized that it was a legacy from when the alarmtimer base
lock was a mutex (due to concerns that we'd be interacting with
the RTC device, which is protected by mutexes).
Since the alarmtimer base is now protected by a spinlock, we can
simply execute alarmtimer functions directly from the hrtimer
callback. Should any future alarmtimer functions sleep, they can
simply manage scheduling any delayed work themselves.
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
This patch addresses a number of minor comment improvements and
other minor issues from Thomas' review of the alarmtimers code.
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
This patch exposes alarm-timers to userland via the posix clock
and timers interface, using two new clockids: CLOCK_REALTIME_ALARM
and CLOCK_BOOTTIME_ALARM. Both clockids behave identically to
CLOCK_REALTIME and CLOCK_BOOTTIME, respectively, but timers
set against the _ALARM suffixed clockids will wake the system if
it is suspended.
Some background can be found here:
https://lwn.net/Articles/429925/
The concept for Alarm-timers was inspired by the Android Alarm
driver (by Arve Hjønnevåg) found in the Android kernel tree.
See: http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=drivers/rtc/alarm.c;h=1250edfbdf3302f5e4ea6194847c6ef4bb7beb1c;hb=android-2.6.36
While the in-kernel interface is pretty similar between
alarm-timers and Android alarm driver, the user-space interface
for the Android alarm driver is via ioctls to a new char device.
As mentioned above, I've instead chosen to export this functionality
via the posix interface, as it seemed a little simpler and avoids
creating duplicate interfaces to things like CLOCK_REALTIME and
CLOCK_MONOTONIC under alternate names (ie:ANDROID_ALARM_RTC and
ANDROID_ALARM_SYSTEMTIME).
The semantics of the Android alarm driver are different from what
this posix interface provides. For instance, threads other then
the thread waiting on the Android alarm driver are able to modify
the alarm being waited on. Also this interface does not allow
the same wakelock semantics that the Android driver provides
(ie: kernel takes a wakelock on RTC alarm-interupt, and holds it
through process wakeup, and while the process runs, until the
process either closes the char device or calls back in to wait
on a new alarm).
One potential way to implement similar semantics may be via
the timerfd infrastructure, but this needs more research.
There may also need to be some sort of sysfs system level policy
hooks that allow alarm timers to be disabled to keep them
from firing at inappropriate times (ie: laptop in a well insulated
bag, mid-flight).
CC: Arve Hjønnevåg <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: Alessandro Zummo <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: John Stultz <[email protected]>
This provides the in kernel interface and infrastructure for
alarm-timers.
Alarm-timers are a hybrid style timer, similar to hrtimers,
but when the system is suspended, the RTC device is set to
fire and wake the system for when the soonest alarm-timer
expires.
The concept for Alarm-timers was inspired by the Android Alarm
driver (by Arve Hjønnevåg) found in the Android kernel tree.
See: http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=drivers/rtc/alarm.c;h=1250edfbdf3302f5e4ea6194847c6ef4bb7beb1c;hb=android-2.6.36
This in-kernel interface should be fairly compatible with the
Android alarm driver in-kernel interface, but has the advantage
of utilizing the new RTC timerqueue code instead of doing direct
RTC manipulation.
CC: Arve Hjønnevåg <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: Alessandro Zummo <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: John Stultz <[email protected]>
In cases where a timerqueue_node or some structure that utilizes
a timerqueue_node is allocated on the stack, gcc would give warnings
caused by the timerqueue_init()'s calling RB_CLEAR_NODE, which
self-references the nodes uninitialized data.
The solution is to create an rb_init_node() function that zeros
the rb_node structure out and then calls RB_CLEAR_NODE(), and
then call the new init function from timerqueue_init().
CC: Thomas Gleixner <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Some platforms cannot implement read_persistent_clock, as
their RTC devices are only accessible when interrupts are enabled.
This keeps them from being used by the timekeeping code on resume
to measure the time in suspend.
The RTC layer tries to work around this, by calling do_settimeofday
on resume after irqs are reenabled to set the time properly. However,
this only corrects CLOCK_REALTIME, and does not properly adjust
the sleep time value. This causes btime in /proc/stat to be incorrect
as well as making the new CLOCK_BOTTTIME inaccurate.
This patch resolves the issue by introducing a new timekeeping hook
to allow the RTC layer to inject the sleep time on resume.
The code also checks to make sure that read_persistent_clock is
nonfunctional before setting the sleep time, so that should the RTC's
HCTOSYS option be configured in on a system that does support
read_persistent_clock we will not increase the total_sleep_time twice.
CC: Arve Hjønnevåg <[email protected]>
CC: Thomas Gleixner <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: John Stultz <[email protected]>
When we register an rtc device at boot, we read the alarm value
in hardware and set the rtc device's aie_timer to that value.
The initial method to do this was to simply call rtc_set_alarm()
with the value read from hardware. However, this may cause problems
as rtc_set_alarm may enable interupts, and the RTC alarm might fire,
which can cause invalid pointer dereferencing since the RTC registration
is not complete.
This patch solves the issue by initializing the rtc_device.aie_timer
y hand via rtc_initialize_alarm(). This avoids any calls to the RTC
hardware which might enable interrupts too early.
CC: Thomas Gleixner <[email protected]>
CC: Alessandro Zummo <[email protected]>
Reported-by: Konrad Rzeszutek Wilk <[email protected]>
Tested-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Now that the genric RTC layer handles much of the RTC functionality,
the rtc.txt documentation needs to be updated to remove outdated information.
CC: Thomas Gleixner <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: Marcelo Roberto Jimenez <[email protected]>
CC: [email protected]
Signed-off-by: John Stultz <[email protected]>
With the generic RTC rework, the UIE mode irqs are handled
in the generic layer, and only hardware specific ioctls
get passed down to the rtc driver layer.
So this patch removes the UIE mode ioctl handling in the rtc
driver layer, which never get used.
CC: Thomas Gleixner <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: Marcelo Roberto Jimenez <[email protected]>
CC: [email protected]
Signed-off-by: John Stultz <[email protected]>
Now that the generic code handles UIE mode irqs via periodic
alarm interrupts, no one calls the
rtc_class_ops->update_irq_enable() method anymore.
This patch removes the driver hooks and implementations of
update_irq_enable if no one else is calling it.
CC: Thomas Gleixner <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: Marcelo Roberto Jimenez <[email protected]>
CC: [email protected]
Signed-off-by: John Stultz <[email protected]>
With the generic rtc code now emulating PIE mode irqs via an
hrtimer, no one calls the rtc_class_ops->irq_set_freq call.
This patch removes the hook and deletes the driver functions
if no one else calls them.
CC: Thomas Gleixner <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: Marcelo Roberto Jimenez <[email protected]>
CC: [email protected]
Signed-off-by: John Stultz <[email protected]>
With PIE mode interrupts now emulated in generic code via an hrtimer,
no one calls rtc_class_ops->irq_set_state(), so this patch removes it
along with driver implementations.
CC: Thomas Gleixner <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: Marcelo Roberto Jimenez <[email protected]>
CC: [email protected]
Signed-off-by: John Stultz <[email protected]>
Mark Brown pointed out a corner case: that RTC alarms should
be allowed to be persistent across reboots if the hardware
supported it.
The rework of the generic layer to virtualize the RTC alarm
virtualized much of the alarm handling, and removed the
code used to read the alarm time from the hardware.
Mark noted if we want the alarm to be persistent across
reboots, we need to re-read the alarm value into the
virtualized generic layer at boot up, so that the generic
layer properly exposes that value.
This patch restores much of the earlier removed
rtc_read_alarm code and wires it in so that we
set the kernel's alarm value to what we find in the
hardware at boot time.
NOTE: Not all hardware supports persistent RTC alarm state across
system reset. rtc-cmos for example will keep the alarm time, but
disables the AIE mode irq. Applications should not expect the RTC
alarm to be valid after a system reset. We will preserve what
we can, to represent the hardware state at boot, but its not
guarenteed.
Further, in the future, with multiplexed RTC alarms, the
soonest alarm to fire may not be the one set via the /dev/rt
ioctls. So an application may set the alarm with RTC_ALM_SET,
but after a reset find that RTC_ALM_READ returns an earlier
time. Again, we preserve what we can, but applications should
not expect the RTC alarm state to persist across a system reset.
Big thanks to Mark for pointing out the issue!
Thanks also to Marcelo for helping think through the solution.
CC: Mark Brown <[email protected]>
CC: Marcelo Roberto Jimenez <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: [email protected]
Reported-by: Mark Brown <[email protected]>
Signed-off-by: John Stultz <[email protected]>
CLOCK_MONOTONIC stops while the system is in suspend. This is because
to applications system suspend is invisible. However, there is a
growing set of applications that are wanting to be suspend-aware,
but do not want to deal with the complications of CLOCK_REALTIME
(which might jump around if settimeofday is called).
For these applications, I propose a new clockid: CLOCK_BOOTTIME.
CLOCK_BOOTTIME is idential to CLOCK_MONOTONIC, except it also
includes any time spent in suspend.
This patch add hrtimer base for CLOCK_BOOTTIME, using
get_monotonic_boottime/ktime_get_boottime, to allow
in kernel users to set timers against.
CC: Jamie Lokier <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: Alexander Shishkin <[email protected]>
CC: Arve Hjønnevåg <[email protected]>
Signed-off-by: John Stultz <[email protected]>
The hrtimer code is written mainly with CLOCK_REALTIME and CLOCK_MONOTONIC
in mind. These are clockids 0 and 1 resepctively. However, if we are
to introduce any new hrtimer bases, using new clockids, we have to skip
the cputimers (clockids 2,3) as well as other clockids that may not impelement
timers.
This patch adds a little bit of indirection between the clockid and
the base, so that we can extend the base by one when we add
a new clockid at number 7 or so.
CC: Jamie Lokier <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: Alexander Shishkin <[email protected]>
CC: Arve Hjønnevåg <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Uwe pointed out that my alarm based UIE emulation is not sufficient
to replace the older timer/polling based UIE emulation on devices
where there is no alarm irq. This causes rtc devices without alarms
to return -EINVAL to UIE ioctls. The fix is to re-instate the old
timer/polling method for devices without alarm irqs.
This patch reverts the following commits:
042620a018 - Remove UIE emulation
1daeddd596 - Cleanup removed UIE emulation declaration
b5cc8ca1c9 - Remove Kconfig symbol for UIE emulation
The emulation mode will still need to be wired-in with a following
patch before it will work.
CC: Uwe Kleine-König <[email protected]>
CC: Thomas Gleixner <[email protected]>
Reported-by: Uwe Kleine-König <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Some rtc drivers use the ioctl method instead of the alarm_irq_enable
method for enabling alarm interupts. With the new virtualized RTC
rework, its important for drivers to use the alarm_irq_enable instead.
This patch converts the drivers that use the AIE ioctl method to
use the alarm_irq_enable method. Other ioctl cmds are left untouched.
I have not been able to test or even compile most of these drivers.
Any help to make sure this change is correct would be appreciated!
CC: Alessandro Zummo <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: Marcelo Roberto Jimenez <[email protected]>
Reported-by: Marcelo Roberto Jimenez <[email protected]>
Tested-by: Marcelo Roberto Jimenez <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Some RTC drivers enable functionality directly via their ioctl method
instead of using the generic ioctl handling code. With the recent
virtualization of the RTC layer, its now important that the generic
layer always be used.
This patch moved the rtc driver ioctl method call to after the generic
ioctl processing is done. This allows hardware specific features or
ioctls to still function, while relying on the generic code for handling
everything else.
This patch on its own may more obviously break rtc drivers that
implement the alarm irq enablement via their ioctl method instead of
implementing the alarm_irq_eanble method. Those drivers will be fixed
in a following patch. Additionaly, those drivers are already likely to
not be functioning reliably without this patch.
CC: Alessandro Zummo <[email protected]>
CC: Marcelo Roberto Jimenez <[email protected]>
CC: Thomas Gleixner <[email protected]>
Reported-by: Marcelo Roberto Jimenez <[email protected]>
Tested-by: Marcelo Roberto Jimenez <[email protected]>
Signed-off-by: John Stultz <[email protected]>
This adds a kernel-internal timekeeping interface to add or subtract
a fixed amount from CLOCK_REALTIME. This makes it so kernel users or
interfaces trying to do so do not have to read the time, then add an
offset and then call settimeofday(), which adds some extra error in
comparision to just simply adding the offset in the kernel timekeeping
core.
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Richard Cochran <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
In reviewing cases where the virtualized interfaces didn't propagate
errors properly, I noticed rtc_read_alarm needed fixing. In doing
so I noticed my RTC rework dropped a memset and that the behavior
of rtc_read_alarm shouldn't be conditionalized on the alarm.enabled
flag (as the alarm may be set, but the irqs may be disabled). So
those were corrected as well.
CC: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
In cases where RTC hardware does not support alarms, the virtualized
RTC interfaces did not have a way to propagate the error up to userland.
This patch extends rtc_timer_enqueue so it catches errors from the hardware
and returns them upwards to the virtualized interfaces. To simplify error
handling, it also internalizes the management of the timer->enabled bit
into rtc_timer_enqueue and rtc_timer_remove.
Also makes rtc_timer_enqueue and rtc_timer_remove static.
Reported-by: David Daney <[email protected]>
Reported-by: Andreas Schwab <[email protected]>
Reported-by: Geert Uytterhoeven <[email protected]>
Diagnosed-by: David Daney <[email protected]>
Tested-by: David Daney <[email protected]>
Signed-off-by: John Stultz <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
rtc_dev_update_irq_enable_emul was removed in commit
042620a018 (UIE emulation is
now handled via hrtimer), but the declaration was missed.
This patch cleans it up.
Signed-off-by: John Stultz <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
This patch reworks a large portion of the generic RTC code
to in-effect virtualize the rtc interrupt code.
The current RTC interface is very much a raw hardware interface.
Via the proc, /dev/, or sysfs interfaces, applciations can set
the hardware to trigger interrupts in one of three modes:
AIE: Alarm interrupt
UIE: Update interrupt (ie: once per second)
PIE: Periodic interrupt (sub-second irqs)
The problem with this interface is that it limits the RTC hardware
so it can only be used by one application at a time.
The purpose of this patch is to extend the RTC code so that we can
multiplex multiple applications event needs onto a single RTC device.
This is done by utilizing the timerqueue infrastructure to manage
a list of events, which cause the RTC hardware to be programmed
to fire an interrupt for the next event in the list.
In order to preserve the functionality of the exsting proc,/dev/ and
sysfs interfaces, we emulate the different interrupt modes as follows:
AIE: We create a rtc_timer dedicated to AIE mode interrupts. There is
only one per device, so we don't change existing interface semantics.
UIE: Again, a dedicated rtc_timer, set for periodic mode, is used
to emulate UIE interrupts. Again, only one per device.
PIE: Since PIE mode interrupts fire faster then the RTC's clock read
granularity, we emulate PIE mode interrupts using a hrtimer. Again,
one per device.
With this patch, the rtctest.c application in Documentation/rtc.txt
passes fine on x86 hardware. However, there may very well still be
bugs, so greatly I'd appreciate any feedback or testing!
Signed-off-by: John Stultz <[email protected]>
LKML Reference: <[email protected]>
Acked-by: Alessandro Zummo <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
CC: Alessandro Zummo <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: Richard Cochran <[email protected]>
In converting the hrtimers to timerqueue, I missed
a spot in hrtimer_run_queues where we loop running
timers. We end up not pulling the new next value out
and instead just use the last next value, causing
boot time hangs in some cases.
The proper fix is to pull timerqueue_getnext each iteration
instead of using a local next value.
Reported-by: Ingo Molnar <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Thomas pointed out a namespace collision between the new timerlist
infrastructure I introduced and the existing timer_list.c
So to avoid confusion, I've renamed the timerlist infrastructure
to timerqueue.
Reported-by: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
John Stultz