linux-toradex.git/kernel/time, branch v3.0.16

Revert "clockevents: Set noop handler in clockevents_exchange_device()"

2012-01-03T18:42:00+00:00

commit 3b87487ac5008072f138953b07505a7e3493327f upstream.

This reverts commit de28f25e8244c7353abed8de0c7792f5f883588c.

It results in resume problems for various people. See for example

  http://thread.gmane.org/gmane.linux.kernel/1233033
  http://thread.gmane.org/gmane.linux.kernel/1233389
  http://thread.gmane.org/gmane.linux.kernel/1233159
  http://thread.gmane.org/gmane.linux.kernel/1227868/focus=1230877

and the fedora and ubuntu bug reports

  https://bugzilla.redhat.com/show_bug.cgi?id=767248
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569

which got bisected down to the stable version of this commit.

Reported-by: Jonathan Nieder 
Reported-by: Phil Miller 
Reported-by: Philip Langdale 
Reported-by: Tim Gardner 
Cc: Thomas Gleixner 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

alarmtimers: Fix time comparison

2011-12-21T20:57:34+00:00

commit c9c024b3f3e07d087974db4c0dc46217fff3a6c0 upstream.

The expiry function compares the timer against current time and does
not expire the timer when the expiry time is >= now. That's wrong. If
the timer is set for now, then it must expire.

Make the condition expiry > now for breaking out the loop.

Signed-off-by: Thomas Gleixner 
Acked-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

clockevents: Set noop handler in clockevents_exchange_device()

2011-12-09T16:52:53+00:00

commit de28f25e8244c7353abed8de0c7792f5f883588c upstream.

If a device is shutdown, then there might be a pending interrupt,
which will be processed after we reenable interrupts, which causes the
original handler to be run. If the old handler is the (broadcast)
periodic handler the shutdown state might hang the kernel completely.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

clocksource: Fix bug with max_deferment margin calculation

2011-12-09T16:52:52+00:00

commit b1f919664d04a8d0ba29cb76673c7ca3325a2006 upstream.

In order to leave a margin of 12.5% we should >> 3 not >> 5.

Signed-off-by: Yang Honggang (Joseph) 
[jstultz: Modified commit subject]
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

tick-broadcast: Stop active broadcast device when replacing it

2011-12-09T16:52:48+00:00

commit c1be84309c58b1e7c6d626e28fba41a22b364c3d upstream.

When a better rated broadcast device is installed, then the current
active device is not disabled, which results in two running broadcast
devices.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

timekeeping: add arch_offset hook to ktime_get functions

2011-12-09T16:52:28+00:00

commit d004e024058a0eaca097513ce62cbcf978913e0a upstream.

ktime_get and ktime_get_ts were calling timekeeping_get_ns()
but later they were not calling arch_gettimeoffset() so architectures
using this mechanism returned 0 ns when calling these functions.

This happened for example when running Busybox's ping which calls
syscall(__NR_clock_gettime, CLOCK_MONOTONIC, ts) which eventually
calls ktime_get. As a result the returned ping travel time was zero.

Signed-off-by: Hector Palacios 
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

alarmtimers: Avoid possible denial of service with high freq periodic timers

2011-10-03T18:40:07+00:00

commit 6af7e471e5a7746b8024d70b4363d3dfe41d36b8 upstream.

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 
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

alarmtimers: Memset itimerspec passed into alarm_timer_get

2011-10-03T18:40:07+00:00

commit ea7802f630d356acaf66b3c0b28c00a945fc35dc upstream.

Following common_timer_get, zero out the itimerspec passed in.

CC: Thomas Gleixner 
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

alarmtimers: Avoid possible null pointer traversal

2011-10-03T18:40:06+00:00

commit 971c90bfa2f0b4fe52d6d9002178d547706f1343 upstream.

We don't check if old_setting is non null before assigning it, so
correct this.

CC: Thomas Gleixner 
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

alarmtimers: Return -ENOTSUPP if no RTC device is present

2011-06-21T23:32:28+00:00

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 
CC: Richard Weinberger 
CC: Thomas Gleixner 
Reported-by: Toralf Förster 
Reported by: Richard Weinberger 
Signed-off-by: John Stultz