rtc_timer_init() is not available when CONFIG_RTC_CLASS=n. Provide a
proper wrapper in the RTC section of alarmtimer.c
Reported-by: NIngo Molnar <mingo@kernel.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>

Sigh, warnings are there for a reason.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: John Stultz <john.stultz@linaro.org>

This is about a 3% speedup on Sandy Bridge.
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

We used to store the wall-to-monotonic offset and the realtime base.
It's faster to precompute the monotonic base.

This is about a 3% speedup on Sandy Bridge for CLOCK_MONOTONIC.
It's much more impressive for CLOCK_MONOTONIC_COARSE.
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

Use than for comparisons, like more than.

CC: John Stultz <john.stultz@linaro.org>
Signed-off-by: NJim Cromie <jim.cromie@gmail.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

Commit 9863c90f (x86, vmware: Remove
deprecated VMI kernel support) removed the only place which set
no_sync_cmos_clock. Since that commit, this variable is never set.
Signed-off-by: NCesar Eduardo Barros <cesarb@cesarb.net>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

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: NJohn Stultz <john.stultz@linaro.org>

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: Njonghwan Choi <jhbird.choi@gmail.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

Since commit 7dffa3c6 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 <levinsasha928@gmail.com>
CC: Thomas Gleixner <tglx@linutronix.de>
Reported-by: NSasha Levin <levinsasha928@gmail.com>
Diagnoised-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NSasha Levin <levinsasha928@gmail.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

While running the latest Linux as guest under VMware in highly
over-committed situations, we have seen cases when the refined TSC
algorithm fails to get a valid tsc_start value in
tsc_refine_calibration_work from multiple attempts. As a result the
kernel keeps on scheduling the tsc_irqwork task for later. Subsequently
after several attempts when it gets a valid start value it goes through
the refined calibration and either bails out or uses the new results.
Given that the kernel originally read the TSC frequency from the
platform, which is the best it can get, I don't think there is much
value in refining it.

So  for systems which get the TSC frequency from the platform we
should skip the refined tsc algorithm.

We can use the TSC_RELIABLE cpu cap flag to detect this, right now it is
set only on VMware and for Moorestown Penwell both of which have there
own TSC calibration methods.
Signed-off-by: NAlok N Kataria <akataria@vmware.com>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Dirk Brandewie <dirk.brandewie@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: stable@kernel.org
[jstultz: Reworked to simply not schedule the refining work,
rather then scheduling the work and bombing out later]
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

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: stable@vger.kernel.org
Reported-by: NRichard Weinberger <richard@nod.at>
Tested-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

The update of the vdso data happens under xtime_lock, so adding a
nested lock is pointless. Just use a seqcount to sync the readers.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

The update of the vdso data happens under xtime_lock, so adding a
nested lock is pointless. Just use a seqcount to sync the readers.
Reviewed-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

Changing the sequence count in update_vsyscall_tz() is completely
pointless.

The vdso code copies the data unprotected. There is no point to change
this as sys_tz is nowhere protected at all. See sys_gettimeofday().
Reviewed-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

There is no global irq lock which makes a syscall magically SMP
safe. Remove the outdated comment concerning do_settimeofday() as
well.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

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 <luto@amacapital.net>
CC: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

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 <luto@amacapital.net>
CC: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

'long secs' is passed as divisor to div_s64, which accepts a 32bit
divisor. On 64bit machines that value is trimmed back from 8 bytes
back to 4, causing a divide by zero when the number is bigger than
(1 << 32) - 1 and all 32 lower bits are 0.

Use div64_long() instead.
Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
Cc: johnstul@us.ibm.com
Link: http://lkml.kernel.org/r/1331829374-31543-2-git-send-email-levinsasha928@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Add a div64_long macro which is used to devide a 64bit number by a long (which
can be 4 bytes on 32bit systems and 8 bytes on 64bit systems).
Suggested-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
Cc: johnstul@us.ibm.com
Link: http://lkml.kernel.org/r/1331829374-31543-1-git-send-email-levinsasha928@gmail.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Shared timer IRQs are not a good solution, however the Geode platform has
no APIC, IRQs are a scarce resource and there is no technical reason to
forbid it rightaway.  Increased latencies and overhead due to sharing are
still better than a driver refusing to load.
Signed-off-by: NJens Rottmann <JRottmann@LiPPERTEmbedded.de>
Acked-by: NAndres Salomon <dilinger@queued.net>
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

On SMP-capable kernels (e.g.  generic distro kernel) the cs5535-clockevt
driver loads but is not actually used.

Setting cpumask to cpu_all_mask works for UP-only kernels, but if compiled
for SMP - though still running on the same UP hardware -
kernel/time/tick-common.c:tick_check_new_device() reads this as
"non-cpu-local" and silently ignores the device.

If we leave cpumask unset clockevents_register_device() will initialize it
and the cs5535-clockevt driver will be used no matter how the kernel was
compiled.  Should anyone ever manage to stick a CS553x in an SMP system
(is this even possible?) then a warning will be printed.  This is fine as
the cs5535-clockevt driver was never written/tested for SMP.

If bisecting led you here this patch may have exposed a pre-existing MFGPT
problem.  Configure for UP-only and re-check.
Signed-off-by: NJens Rottmann <JRottmann@LiPPERTEmbedded.de>
Acked-by: NAndres Salomon <dilinger@queued.net>
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

As of v2.6.38 this counter is being maintained without ever being
read.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Link: http://lkml.kernel.org/r/4F4787930200007800074A10@nat28.tlf.novell.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

This commit:

  12d6d412: clocksource: scx200_hrt: Convert scx200 to use clocksource_register_hz

Breaks the build on x86-32:

  drivers/clocksource/scx200_hrt.c: In function ‘init_hrt_clocksource’:
  drivers/clocksource/scx200_hrt.c:95:0: error: unterminated argument list invoking macro "pr_info"
  drivers/clocksource/scx200_hrt.c:84:2: error: ‘pr_info’ undeclared (first use in this function)

It could not possibly have been build tested, because it had this mismerge:

	pr_info("enabling scx200 high-res timer (%s MHz +%d ppm)\n",
	printk(KERN_INFO "enabling scx200 high-res timer (%s MHz +%d ppm)\n",
		mhz27 ? "27":"1", ppm);

Cc: Jim Cromie <jim.cromie@gmail.com>
Cc: John Stultz <john.stultz@linaro.org>
Link: http://lkml.kernel.org/n/tip-jceb26fns5w7tv8edlivhxpa@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>

For each logical CPU that is coming online, we spend 20msec for
checking the TSC synchronization. And as this is done
sequentially for each logical CPU boot, this time gets added up
depending on the number of logical CPU's supported by the
platform.

Minimize this by using the socket topology information.

If the target CPU coming online doesn't have any of its
core-siblings online, a timeout of 20msec will be used for the
TSC-warp measurement loop. Otherwise a smaller timeout of 2msec
will be used, as we have some information about this socket
already (and this information grows as we have more and more
logical-siblings in that socket).

Ideally we should be able to skip the TSC sync check on the
other core-siblings, if the first logical CPU in a socket passed
the sync test. But as the TSC is per-logical CPU and can
potentially be modified wrongly by the bios before the OS boot,
TSC sync test for smaller duration should be able to catch such
errors. Also this will catch the condition where all the cores
in the socket doesn't get reset at the same time.

For example, with this modification, time spent in TSC sync
checks on a 4 socket 10-core with HT system gets reduced from
1580msec to 212msec.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Acked-by: NArjan van de Ven <arjan@linux.intel.com>
Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Jack Steiner <steiner@sgi.com>
Cc: venki@google.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/1328581940.29790.20.camel@sbsiddha-desk.sc.intel.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

Merge branch 'fortglx/3.4/clocksource' of git://git.linaro.org/people/jstultz/linux into timers/core

idle_cpu() is called on irq entry to guess if we need to call
tick_check_idle(). This way we can catch up with jiffies if the tick
was stopped, stop accounting idle time during the interrupt and
maintain the sched clock if it is unstable.

But if we are going to exit the idle loop to schedule a new task (ie:
if we have a task in the runqueue or a remotely enqueued ttwu to
perform), the idle_cpu() check will return 0 such that we miss the
call to tick_check_idle() for all interrupts happening before we
schedule the new task.

As a result these interrupts and the softirqs coming along may deal
with stale jiffies values, bad sched clock values, and won't substract
their time from the idle time accounting.

Fix this with using is_idle_task() instead that strictly checks that
we are running the idle task, without caring about the fact we are
going to schedule a task soon.
Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Ingo Molnar <mingo@elte.hu>
Link: http://lkml.kernel.org/r/1327427984-23282-3-git-send-email-fweisbec@gmail.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

ts->inidle is set by tick_nohz_idle_enter() and unset by
tick_nohz_idle_exit(). However these two calls are assumed
to be always paired. This means that by the time we call
tick_nohz_idle_exit(), ts->inidle is supposed to be always
set to 1.

Remove the checks for ts->inidle in tick_nohz_idle_exit().
This simplifies a bit the code and improves its debuggability
(ie: ensure the call is paired with a tick_nohz_idle_enter()
call).
Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
Reviewed-by: NYong Zhang <yong.zhang0@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Ingo Molnar <mingo@elte.hu>
Link: http://lkml.kernel.org/r/1327427984-23282-2-git-send-email-fweisbec@gmail.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

There is no reason to call update_ts_time_stat from tick_nohz_start_idle
anymore (after e0e37c20 sched: Eliminate the ts->idle_lastupdate field)
when we updated idle_lastupdate unconditionally.

We haven't set idle_active yet and do not provide last_update_time so
the whole call end up being just 2 wasted branches.
Signed-off-by: NMichal Hocko <mhocko@suse.cz>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Link: http://lkml.kernel.org/r/1322755222-6951-1-git-send-email-mhocko@suse.czSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Platforms with Always Running APIC Timer doesn't use the broadcast timer
but the kernel is leaving the broadcast timer (HPET in this case)
in oneshot mode.

On these platforms, before the switch to oneshot mode, broadcast device is
actually in shutdown mode. Code checks for empty tick_broadcast_mask and
avoids going into the periodic mode.

During switch to oneshot mode, add the same tick_broadcast_mask checks in the
tick_broadcast_switch_to_oneshot() and avoid the broadcast device going into
the oneshot mode.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: john stultz <johnstul@us.ibm.com>
Cc: venki@google.com
Link: http://lkml.kernel.org/r/1320452301.15071.16.camel@sbsiddha-desk.sc.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

One small bug fix from Axel plus a fix for a build failure in unrealistic
but commonly built configs which for some reason manage to survive for
an awfully long time in -next without any reports.

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: Fix getting voltage in max8649_enable_time()
  regulator: Fix mc13xxx regulator modular build (again)

Quoth BenH:
 "Here are a few powerpc fixes for 3.3, all pretty trivial.  I also
  added the patch to define GET_IP/SET_IP so we can use some more
  asm-generic goodness."

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc/pseries/eeh: Fix crash when error happens during device probe
  powerpc/pseries: Fix partition migration hang in stop_topology_update
  powerpc/powernv: Disable interrupts while taking phb->lock
  powerpc: Fix WARN_ON in decrementer_check_overflow
  powerpc/wsp: Fix IRQ affinity setting
  powerpc: Implement GET_IP/SET_IP
  powerpc/wsp: Permanently enable PCI class code workaround

MMC fixes for 3.3-rc4:
 * The most visible fix here is against a regression introduced in 3.3-rc1
   that ran cards in Ultra High Speed mode even when they failed to initialize
   in that mode, leading to lower-speed cards failing to mount.
 * A lockdep warning introduced in 3.3-rc1 is fixed.
 * Various other small driver fixes, most notably for a NULL dereference
   when using highmem with dw_mmc.

* tag 'mmc-fixes-for-3.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc:
  mmc: dw_mmc: Fix PIO mode with support of highmem
  mmc: atmel-mci: save and restore sdioirq when soft reset is performed
  mmc: block: Init ro_lock sysfs attr to fix lockdep warnings
  mmc: sh_mmcif: fix late delayed work initialisation
  mmc: tmio_mmc: fix card eject during IO with DMA
  mmc: core: Fix comparison issue in mmc_compare_ext_csds
  mmc: core: Fix PowerOff Notify suspend/resume
  mmc: sdhci-pci: set Medfield SDIO as non-removable
  mmc: core: add the capability for broken voltage
  mmc: core: Fix low speed mmc card detection failure
  mmc: esdhc: set the timeout to the max value
  mmc: esdhc: add PIO mode support
  mmc: core: Ensure clocks are always enabled before host interaction
  mmc: of_mmc_spi: fix little endian support
  mmc: core: UHS sdio card that fails should not exceed 50MHz
  mmc: esdhc: fix errors when booting kernel on Freescale eSDHC version 2.3

Merge tag 'stable/for-linus-fixes-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

Two fixes for VCPU offlining; One to fix the string format exposed
by the xen-pci[front|back] to conform to the one used in majority of
PCI drivers; Two fixes to make the code more resilient to invalid
configurations.
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

* tag 'stable/for-linus-fixes-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  xenbus_dev: add missing error check to watch handling
  xen/pci[front|back]: Use %d instead of %1x for displaying PCI devfn.
  xen pvhvm: do not remap pirqs onto evtchns if !xen_have_vector_callback
  xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while atomic.
  xen/bootup: During bootup suppress XENBUS: Unable to read cpu state

sound fixes for 3.3-rc4

Basically all small fixes suited as rc4: a few HD-audio regression fixes,
a stable fix for an old Dell laptop with intel8x0, and a simple fix for
ASoC fsi.

* tag 'sound-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: intel8x0: Fix default inaudible sound on Gateway M520
  ALSA: hda - Fix silent speaker output on Acer Aspire 6935
  ALSA: hda - Fix initialization of secondary capture source on VT1705
  ASoC: fsi: fixup fsi_pointer() calculation method
  ALSA: hda - Fix mute-LED VREF value for new HP laptops

BugLink: https://bugs.launchpad.net/bugs/930842

The reporter states that audio is inaudible by default without muting
'External Amplifier'. Add a quirk to handle his SSID so that changing
the control is not necessary.
Reported-and-tested-by: NBenjamin Carlson <elderbubba0810@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: NDaniel T Chen <crimsun@ubuntu.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

A simple fix from Morimoto-san for the pointer() operation in the FSI
driver.

* git://git.samba.org/sfrench/cifs-2.6:
  cifs: don't return error from standard_receive3 after marking response malformed
  cifs: request oplock when doing open on lookup
  cifs: fix error handling when cifscreds key payload is an error

This updates the sha512 fix so that it doesn't cause excessive stack
usage on i386.  This is done by reverting to the original code, and
avoiding the W duplication by moving its initialisation into the loop.

As the underlying code is in fact the one that we have used for years,
I'm pushing this now instead of postponing to the next cycle.

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: sha512 - Avoid stack bloat on i386
  crypto: sha512 - Use binary and instead of modulus