kernel_samsung_smdk4412/kernel/time, branch replicant-6.0

Input: add infrastructure for selecting clockid for event time stamps

2016-03-16T11:34:14+00:00

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 
Reviewed-by: Daniel Kurtz 
Signed-off-by: Dmitry Torokhov 

Conflicts:
	include/linux/input.h

Change-Id: I7b9b442dcd7930a1e72c688327e6fb7275107128

timekeeping: fix 32-bit overflow in get_monotonic_boottime

2016-02-20T02:25:02+00:00

fixed upstream in v3.6 by ec145babe754f9ea1079034a108104b6001e001c

get_monotonic_boottime adds three nanonsecond values stored
in longs, followed by an s64.  If the long values are all
close to 1e9 the first three additions can overflow and
become negative when added to the s64.  Cast the first
value to s64 so that all additions are 64 bit.

Signed-off-by: Colin Cross 
[jstultz: Fished this out of the AOSP commong.git tree. This was
fixed upstream in v3.6 by ec145babe754f9ea1079034a108104b6001e001c]
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman 
Change-Id: If4ec90946bb49b022403c14e63903b3027dd5c58

Revert "tick: Cleanup NOHZ per cpu data on cpu down"

2016-01-13T13:38:06+00:00

andip71: This was a bug introduced in upstream to 3.0.79 which impacts CPU frequency scaling

This reverts commit b9cbfd27308999d2ae56d1d341a3a77f91d04a19.

Change-Id: I20aec7487cd7e426d52ce1724ee6216e594ba199

Merge remote-tracking branch 'korg/linux-3.0.y' into cm-13.0

2015-11-10T19:01:25+00:00

Conflicts:
	crypto/algapi.c
	drivers/gpu/drm/i915/i915_debugfs.c
	drivers/gpu/drm/i915/intel_display.c
	drivers/video/fbmem.c
	include/linux/nls.h
	kernel/cgroup.c
	kernel/signal.c
	kernel/timeconst.pl
	net/ipv4/ping.c

Change-Id: I1f532925d1743df74d66bcdd6fc92f05c72ee0dd

tick: Prevent uncontrolled switch to oneshot mode

2013-07-28T23:18:24+00:00

commit 1f73a9806bdd07a5106409bbcab3884078bd34fe upstream.

When the system switches from periodic to oneshot mode, the broadcast
logic causes a possibility that a CPU which has not yet switched to
oneshot mode puts its own clock event device into oneshot mode without
updating the state and the timer handler.

CPU0				CPU1
				per cpu tickdev is in periodic mode
				and switched to broadcast

Switch to oneshot mode
 tick_broadcast_switch_to_oneshot()
  cpumask_copy(tick_oneshot_broacast_mask,
	       tick_broadcast_mask);

  broadcast device mode = oneshot

				Timer interrupt

				irq_enter()
				 tick_check_oneshot_broadcast()
				  dev->set_mode(ONESHOT);

				tick_handle_periodic()
				 if (dev->mode == ONESHOT)
				   dev->next_event += period;
				   FAIL.

We fail, because dev->next_event contains KTIME_MAX, if the device was
in periodic mode before the uncontrolled switch to oneshot happened.

We must copy the broadcast bits over to the oneshot mask, because
otherwise a CPU which relies on the broadcast would not been woken up
anymore after the broadcast device switched to oneshot mode.

So we need to verify in tick_check_oneshot_broadcast() whether the CPU
has already switched to oneshot mode. If not, leave the device
untouched and let the CPU switch controlled into oneshot mode.

This is a long standing bug, which was never noticed, because the main
user of the broadcast x86 cannot run into that scenario, AFAICT. The
nonarchitected timer mess of ARM creates a gazillion of differently
broken abominations which trigger the shortcomings of that broadcast
code, which better had never been necessary in the first place.

Reported-and-tested-by: Stehle Vincent-B46079 
Reviewed-by: Stephen Boyd 
Cc: John Stultz ,
Cc: Mark Rutland 
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1307012153060.4013@ionos.tec.linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

tick: Cleanup NOHZ per cpu data on cpu down

2013-05-19T17:04:40+00:00

commit 4b0c0f294f60abcdd20994a8341a95c8ac5eeb96 upstream.

Prarit reported a crash on CPU offline/online. The reason is that on
CPU down the NOHZ related per cpu data of the dead cpu is not cleaned
up. If at cpu online an interrupt happens before the per cpu tick
device is registered the irq_enter() check potentially sees stale data
and dereferences a NULL pointer.

Cleanup the data after the cpu is dead.

Reported-by: Prarit Bhargava 
Cc: Mike Galbraith 
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1305031451561.2886@ionos
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

clockevents: Set dummy handler on CPU_DEAD shutdown

2013-05-08T02:57:26+00:00

commit 6f7a05d7018de222e40ca003721037a530979974 upstream.

Vitaliy reported that a per cpu HPET timer interrupt crashes the
system during hibernation. What happens is that the per cpu HPET timer
gets shut down when the nonboot cpus are stopped. When the nonboot
cpus are onlined again the HPET code sets up the MSI interrupt which
fires before the clock event device is registered. The event handler
is still set to hrtimer_interrupt, which then crashes the machine due
to highres mode not being active.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700333

There is no real good way to avoid that in the HPET code. The HPET
code alrady has a mechanism to detect spurious interrupts when event
handler == NULL for a similar reason.

We can handle that in the clockevent/tick layer and replace the
previous functional handler with a dummy handler like we do in
tick_setup_new_device().

The original clockevents code did this in clockevents_exchange_device(),
but that got removed by commit 7c1e76897 (clockevents: prevent
clockevent event_handler ending up handler_noop) which forgot to fix
it up in tick_shutdown(). Same issue with the broadcast device.

Reported-by: Vitaliy Fillipov 
Cc: Ben Hutchings 
Cc: 700333@bugs.debian.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

clockevents: Don't allow dummy broadcast timers

2013-03-28T19:06:03+00:00

commit a7dc19b8652c862d5b7c4d2339bd3c428bd29c4a upstream.

Currently tick_check_broadcast_device doesn't reject clock_event_devices
with CLOCK_EVT_FEAT_DUMMY, and may select them in preference to real
hardware if they have a higher rating value. In this situation, the
dummy timer is responsible for broadcasting to itself, and the core
clockevents code may attempt to call non-existent callbacks for
programming the dummy, eventually leading to a panic.

This patch makes tick_check_broadcast_device always reject dummy timers,
preventing this problem.

Signed-off-by: Mark Rutland 
Cc: linux-arm-kernel@lists.infradead.org
Cc: Jon Medhurst (Tixy) 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

Merge remote-tracking branch 'kernelorg/linux-3.0.y' into 3_0_64

2013-02-27T14:19:08+00:00

Conflicts:
	arch/arm/Kconfig
	arch/arm/include/asm/hwcap.h
	arch/arm/kernel/smp.c
	arch/arm/plat-samsung/adc.c
	drivers/gpu/drm/i915/i915_reg.h
	drivers/gpu/drm/i915/intel_drv.h
	drivers/mmc/core/sd.c
	drivers/net/tun.c
	drivers/net/usb/usbnet.c
	drivers/regulator/max8997.c
	drivers/usb/core/hub.c
	drivers/usb/host/xhci.h
	drivers/usb/serial/qcserial.c
	fs/jbd2/transaction.c
	include/linux/migrate.h
	kernel/sys.c
	kernel/time/timekeeping.c
	lib/genalloc.c
	mm/memory-failure.c
	mm/memory_hotplug.c
	mm/mempolicy.c
	mm/page_alloc.c
	mm/vmalloc.c
	mm/vmscan.c
	mm/vmstat.c
	scripts/Kbuild.include

Change-Id: I91e2d85c07320c7ccfc04cf98a448e89bed6ade6

time: Move ktime_t overflow checking into timespec_valid_strict

2012-10-02T16:47:52+00:00

commit cee58483cf56e0ba355fdd97ff5e8925329aa936 upstream

Andreas Bombe reported that the added ktime_t overflow checking added to
timespec_valid in commit 4e8b14526ca7 ("time: Improve sanity checking of
timekeeping inputs") was causing problems with X.org because it caused
timeouts larger then KTIME_T to be invalid.

Previously, these large timeouts would be clamped to KTIME_MAX and would
never expire, which is valid.

This patch splits the ktime_t overflow checking into a new
timespec_valid_strict function, and converts the timekeeping codes
internal checking to use this more strict function.

Reported-and-tested-by: Andreas Bombe 
Cc: Zhouping Liu 
Cc: Ingo Molnar 
Cc: Prarit Bhargava 
Cc: Thomas Gleixner 
Signed-off-by: John Stultz 
Signed-off-by: Linus Torvalds 
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman