Commit Graph

76 Commits

Author SHA1 Message Date
Vaibhav Jain da96aea0ed rtc: interface: Validate alarm-time before handling rollover
In function __rtc_read_alarm() its possible for an alarm time-stamp to
be invalid even after replacing missing components with current
time-stamp. The condition 'alarm->time.tm_year < 70' will trigger this
case and will cause the call to 'rtc_tm_to_time64(&alarm->time)'
return a negative value for variable t_alm.

While handling alarm rollover this negative t_alm (assumed to seconds
offset from '1970-01-01 00:00:00') is converted back to rtc_time via
rtc_time64_to_tm() which results in this error log with seemingly
garbage values:

"rtc rtc0: invalid alarm value: -2-1--1041528741
2005511117:71582844:32"

This error was generated when the rtc driver (rtc-opal in this case)
returned an alarm time-stamp of '00-00-00 00:00:00' to indicate that
the alarm is disabled. Though I have submitted a separate fix for the
rtc-opal driver, this issue may potentially impact other
existing/future rtc drivers.

To fix this issue the patch validates the alarm time-stamp just after
filling up the missing datetime components and if rtc_valid_tm() still
reports it to be invalid then bails out of the function without
handling the rollover.

Reported-by: Steve Best <sbest@redhat.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2017-05-31 13:04:54 +02:00
Thomas Gleixner 8b0e195314 ktime: Cleanup ktime_set() usage
ktime_set(S,N) was required for the timespec storage type and is still
useful for situations where a Seconds and Nanoseconds part of a time value
needs to be converted. For anything where the Seconds argument is 0, this
is pointless and can be replaced with a simple assignment.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
2016-12-25 17:21:22 +01:00
Thomas Gleixner 2456e85535 ktime: Get rid of the union
ktime is a union because the initial implementation stored the time in
scalar nanoseconds on 64 bit machine and in a endianess optimized timespec
variant for 32bit machines. The Y2038 cleanup removed the timespec variant
and switched everything to scalar nanoseconds. The union remained, but
become completely pointless.

Get rid of the union and just keep ktime_t as simple typedef of type s64.

The conversion was done with coccinelle and some manual mopping up.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
2016-12-25 17:21:22 +01:00
Uwe Kleine-König 6785b3b60b rtc: fix a typo and reduce three empty lines to one
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-07-11 23:22:35 +02:00
Colin Ian King 2b2f5ff00f rtc: interface: ignore expired timers when enqueuing new timers
This patch fixes a RTC wakealarm issue, namely, the event fires during
hibernate and is not cleared from the list, causing hwclock to block.

The current enqueuing does not trigger an alarm if any expired timers
already exist on the timerqueue. This can occur when a RTC wake alarm
is used to wake a machine out of hibernate and the resumed state has
old expired timers that have not been removed from the timer queue.
This fix skips over any expired timers and triggers an alarm if there
are no pending timers on the timerqueue. Note that the skipped expired
timer will get reaped later on, so there is no need to clean it up
immediately.

The issue can be reproduced by putting a machine into hibernate and
waking it with the RTC wakealarm.  Running the example RTC test program
from tools/testing/selftests/timers/rtctest.c after the hibernate will
block indefinitely.  With the fix, it no longer blocks after the
hibernate resume.

BugLink: http://bugs.launchpad.net/bugs/1333569

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-06-04 15:43:22 +02:00
Uwe Kleine-König d68778b80d rtc: initialize output parameter for read alarm to "uninitialized"
rtc drivers are supposed to set values they don't support to -1. To
simplify this for drivers and also make it harder for them to get it
wrong initialize the values to -1.

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-05-30 01:37:11 +02:00
Joshua Clayton b3967067c2 rtc: Add functions to set and read rtc offset
A number of rtc devices, such as the NXP pcf2123 include a facility
to adjust the clock in order to compensate for temperature or a
crystal, capacitor, etc, that results in the rtc clock not running
at exactly 32.768 kHz.

Data sheets I have seen refer to this as a clock offset, and measure it
in parts per million, however they often reference ppm to 2 digits of
precision, which makes integer ppm less than ideal.

We use parts per billion, which more than covers the precision needed
and works nicely within 32 bits

Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2016-03-14 17:08:15 +01:00
viresh kumar e7cba884af rtc: Drop (un)likely before IS_ERR(_OR_NULL)
IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
is no need to do that again from its callers. Drop it.

gemini driver was using likely() for a failure case while the rtc driver
is getting registered. That looks wrong and it should really be
unlikely. But because we are killing all the unlikely() flags, lets kill
that too.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-09-05 13:19:09 +02:00
Xunlei Pang c86a6c2895 rtc: interface: Remove rtc_set_mmss()
Now rtc_set_mmss() has no users, just remove it.

We still have rtc_set_time() doing similar things.

Signed-off-by: Xunlei Pang <pang.xunlei@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-06-25 01:13:43 +02:00
Krzysztof Kozlowski 73744a64aa rtc: interface: Remove unused return value from rtc_timer_cancel()
The rtc_timer_cancel() always returns 0 and cannot fail (calls only
other void-returning functions).

Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-06-19 20:03:20 +02:00
Aaro Koskinen d0bddb512d drivers/rtc/interface.c: __rtc_read_time: reduce log level
__rtc_read_time logs should be debug logs instead of error logs.

For example, when the RTC clock is not set, it's not really useful
to print a kernel error log every time someone tries to read the clock:

	~ # hwclock -r
	[  604.508263] rtc rtc0: read_time: fail to read
	hwclock: RTC_RD_TIME: Invalid argument

If there's a real error, it's likely that lower level or higher level
code will tell it anyway. Make these logs debug logs, and also print
the error code for the read failure.

Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-17 09:04:01 -04:00
Xunlei Pang 8e4ff1a81a drivers/rtc: Provide y2038 safe rtc_class_ops.set_mmss() replacement
Currently the rtc_class_op's set_mmss() function takes a 32-bit
second value (on 32-bit systems), which is problematic for dates
past y2038.

This patch provides a safe version named set_mmss64() using
y2038 safe time64_t.

After this patch, set_mmss() is deprecated and all its users
will be fixed to use set_mmss64(), it can be removed when having
no users.

Signed-off-by: Xunlei Pang <pang.xunlei@linaro.org>
[jstultz: Add whitespace fix for checkpatch]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1427945681-29972-8-git-send-email-john.stultz@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-03 08:18:24 +02:00
Xunlei Pang bc10aa93a8 rtc: Update interface.c to use y2038-safe time interfaces
Currently, interface.c uses y2038 problematic rtc_tm_to_time()
and rtc_time_to_tm(). So replace them with their corresponding
y2038-safe versions: rtc_tm_to_time64() and rtc_time64_to_tm().

Cc: pang.xunlei <pang.xunlei@linaro.org>
Cc: Arnd Bergmann <arnd.bergmann@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Xunlei Pang <pang.xunlei@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
2015-01-23 17:21:55 -08:00
Xunlei Pang 6528b88995 rtc: refine rtc_timer_do_work() to consider other set alarm failures
rtc_timer_do_work() only judges -ETIME failure of__rtc_set_alarm(), but
doesn't handle other failures like -EIO, -EBUSY, etc.

If there is a failure other than -ETIME, the next rtc_timer will stay in
the timerqueue.  Then later rtc_timers will be enqueued directly because
they have a later expires time, so the alarm irq will never be programmed.

When such failures happen, this patch will retry __rtc_set_alarm(), if
still can't program the alarm time, it will remove current rtc_timer from
timerqueue and fetch next one, thus preventing it from affecting other rtc
timers.

Signed-off-by: Xunlei Pang <pang.xunlei@linaro.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Arnd Bergmann <arnd.bergmann@linaro.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-10 17:41:16 -08:00
Hyogi Gim 16682c86d2 drivers/rtc/interface.c: check the validation of rtc_time in __rtc_read_time
Some rtc devices always return '0' when rtc_class_ops.read_time is
called.  So if rtc_time isn't verified in callback, rtc interface cannot
know whether rtc_time is valid.

Check rtc_time by using 'rtc_valid_tm' in '__rtc_read_time'.  And add
the message for debugging.

Signed-off-by: Hyogi Gim <hyogi.gim@lge.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-10 17:41:13 -08:00
Hyogi Gim ca6dc2dab9 drivers/rtc/interface.c: check the error after __rtc_read_time()
In __rtc_set_alarm(), the error after __rtc_read_time() is not checked.
If rtc device fail to read time, we cannot guarantee the following
process.

Add the verification code for returned __rtc_read_time() error.

Signed-off-by: Hyogi Gim <hyogi.gim@lge.com>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-08-08 15:57:19 -07:00
Ales Novak ee1d901468 drivers/rtc/interface.c: fix infinite loop in initializing the alarm
In __rtc_read_alarm(), if the alarm time retrieved by
rtc_read_alarm_internal() from the device contains invalid values (e.g.
month=2,mday=31) and the year not set (=-1), the initialization will
loop infinitely because the year-fixing loop expects the time being
invalid due to leap year.

Fix reduces the loop to the leap years and adds final validity check.

Signed-off-by: Ales Novak <alnovak@suse.cz>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Reported-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-06-06 16:08:06 -07:00
Alessandro Zummo 131c9cc832 rtc: verify a critical argument to rtc_update_irq() before using it
This small addition to the core simplifies code in the drivers and makes
them more robust when handling shared IRQs.

Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-04-03 16:21:22 -07:00
Zoran Markovic 14d0e347ea rtc: Keep system awake until all expired RTC timers are handled
Current implementation of RTC interface allows for system suspend to
occur in the following cases:
(a) if a timer is set in the past and rtc_timer_do_work() is scheduled
to handle it, and
(b) if rtc_timer_do_work() is called to handle expired timers whose
handlers implement a preemption point.

A pending suspend request may be honoured in the above cases causing
timer handling to be delayed until after the next resume. This is
undesirable since timer handlers may have time-critical code to execute.

This patch makes sure that the system stays awake until all expired
timers are handled.

Note that all calls to pm_stay_awake() are eventually paired with
the single pm_relax() call in rtc_timer_do_work(), which is launched
using schedule_work().

Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Arve Hjonnevag <arve@android.com>
Cc: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
2013-07-22 09:38:25 -07:00
Chris Brand 0734e27f0b drivers/rtc/interface.c: return -EBUSY, not -EACCES when device is busy
If rtc->irq_task is non-NULL and task is NULL, they always
rtc_irq_set_freq(), whenever err is set to -EBUSY it will then immediately
be set to -EACCES, misleading the caller as to the underlying problem.

Signed-off-by: Chris Brand <chris.brand@broadcom.com>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-07-03 16:08:00 -07:00
Sachin Kamat 3ff2e13ce1 drivers/rtc/interface.c: fix checkpatch errors
Fixes the following types of errors:
  ERROR: "foo* bar" should be "foo *bar"
  ERROR: else should follow close brace '}'
  WARNING: braces {} are not necessary for single statement blocks

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-07-03 16:07:46 -07:00
Michał Mirosław 9f3b795a62 driver-core: constify data for class_find_device()
All in-kernel users of class_find_device() don't really need mutable
data for match callback.

In two places (kernel/power/suspend_test.c, drivers/scsi/osd/osd_uld.c)
this patch changes match callbacks to use const search data.

The const is propagated to rtc_class_open() and power_supply_get_by_name()
parameters.

Note that there's a dev reference leak in suspend_test.c that's not
touched in this patch.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-02-06 12:18:56 -08:00
NeilBrown 7523ceed42 RTC: Avoid races between RTC alarm wakeup and suspend.
If an RTC alarm fires just as suspend is happening, it is possible for
suspend to complete and the alarm to be missed.

To avoid the race, we must register the event with the PM core.

As the event is made visible to userspace through a thread which is
only scheduled by the interrupt, we need a pm_stay_awake/pm_relax
pair preventing suspend from the interrupt until the thread completes
its work.

This makes the pm_wakeup_event() call in cmos_interrupt unnecessary as
it provides suspend protection for all RTCs that use rtc_update_irq.

Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-08-08 20:49:16 +02:00
John Stultz 4a649903f9 rtc: Provide flag for rtc devices that don't support UIE
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: Richard Weinberger <richard@nod.at>
Tested-by: Richard Weinberger <richard@nod.at>
Signed-off-by: John Stultz <john.stultz@linaro.org>
2012-03-15 18:23:10 -07:00
Rabin Vincent 41c7f74242 rtc: Disable the alarm in the hardware (v2)
Currently, the RTC code does not disable the alarm in the hardware.

This means that after a sequence such as the one below (the files are in the
RTC sysfs), the box will boot up after 2 minutes even though we've
asked for the alarm to be turned off.

	# echo $((`cat since_epoch`)+120) > wakealarm
	# echo 0 > wakealarm
	# poweroff

Fix this by disabling the alarm when there are no timers to run.

The original version of this patch was reverted. This version
disables the irq directly instead of setting a disabled timer
in the future.

Cc: stable@kernel.org
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
[Merged in the second revision from Rabin]
Signed-off-by: John Stultz <john.stultz@linaro.org>
2012-01-26 19:41:42 -08:00
NeilBrown 5f9679d29c rtc: Expire alarms after the time is set. (v2)
If the alarm time programming in the rtc is ever in the past, it won't fire,
and any other alarm will be queued after it so they won't fire either.

So any time that the alarm might be in the past, we need to trigger
the irq handler to ensure the old alarm is cleared and the timer queue
is fully in the future.

This is done whenever the RTC clock is set.

This is the second revision of this patch, which was earlier reverted.
This version avoids the initialization problem, which is handled by
a different patch.

Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: NeilBrown <neilb@suse.de>
[Remove problematic initialization change, update commit log, also
catch set_mmss case -jstultz]
Signed-off-by: John Stultz <john.stultz@linaro.org>
2012-01-26 19:41:36 -08:00
John Stultz bd729d72b4 rtc: Avoid setting alarm to a time in the past
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 <neilb@suse.de>
Tested-by: NeilBrown <neilb@suse.de>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: John Stultz <john.stultz@linaro.org>
2012-01-26 19:41:30 -08:00
Ben Hutchings e74a8f2edb drivers/rtc/interface.c: fix alarm rollover when day or month is out-of-range
Commit f44f7f96a2 ("RTC: Initialize kernel state from RTC") introduced a
potential infinite loop.  If an alarm time contains a wildcard month and
an invalid day (> 31), or a wildcard year and an invalid month (>= 12),
the loop searching for the next matching date will never terminate.  Treat
the invalid values as wildcards.

Fixes <http://bugs.debian.org/646429>, <http://bugs.debian.org/653331>

Reported-by: leo weppelman <leoweppelman@googlemail.com>
Reported-by: "P. van Gaans" <mailme667@yahoo.co.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-01-10 16:30:53 -08:00
Linus Torvalds f423fc627b Revert "rtc: Expire alarms after the time is set."
This reverts commit 93b2ec0128.

The call to "schedule_work()" in rtc_initialize_alarm() happens too
early, and can cause oopses at bootup

Neil Brown explains why we do it:

  "If you set an alarm in the future, then shutdown and boot again after
   that time, then you will end up with a timer_queue node which is in
   the past.

   When this happens the queue gets stuck.  That entry-in-the-past won't
   get removed until and interrupt happens and an interrupt won't happen
   because the RTC only triggers an interrupt when the alarm is "now".

   So you'll find that e.g.  "hwclock" will always tell you that
   'select' timed out.

   So we force the interrupt work to happen at the start just in case."

and has a patch that convert it to do things in-process rather than with
the worker thread, but right now it's too late to play around with this,
so we just revert the patch that caused problems for now.

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Requested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Requested-by: John Stultz <john.stultz@linaro.org>
Cc: Neil Brown <neilb@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-01-04 07:57:22 -08:00
Linus Torvalds 157e8bf8b4 Revert "rtc: Disable the alarm in the hardware"
This reverts commit c0afabd3d5.

It causes failures on Toshiba laptops - instead of disabling the alarm,
it actually seems to enable it on the affected laptops, resulting in
(for example) the laptop powering on automatically five minutes after
shutdown.

There's a patch for it that appears to work for at least some people,
but it's too late to play around with this, so revert for now and try
again in the next merge window.

See for example

	http://bugs.debian.org/652869

Reported-and-bisected-by: Andreas Friedrich <afrie@gmx.net> (Toshiba Tecra)
Reported-by: Antonio-M. Corbi Bellot <antonio.corbi@ua.es> (Toshiba Portege R500)
Reported-by: Marco Santos <marco.santos@waynext.com> (Toshiba Portege Z830)
Reported-by: Christophe Vu-Brugier <cvubrugier@yahoo.fr>  (Toshiba Portege R830)
Cc: Jonathan Nieder <jrnieder@gmail.com>
Requested-by: John Stultz <john.stultz@linaro.org>
Cc: stable@kernel.org  # for the versions that applied this
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-01-03 17:32:13 -08:00
NeilBrown 93b2ec0128 rtc: Expire alarms after the time is set.
If the alarm time programming in the rtc is ever in the past, it won't fire,
and any other alarm will be queued after it so they won't fire either.

So any time that the alarm might be in the past, we need to trigger
the irq handler to ensure the old alarm is cleared and the timer queue
is fully in the future.

This can happen:
 - when we first initialise the alarm
 - when we set the time in the rtc.

so follow both of these by scheduling the timer work function.

CC: stable@kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
[Also catch set_mmss case -jstultz]
Signed-off-by: John Stultz <john.stultz@linaro.org>
2011-12-13 12:26:11 -08:00
Linus Torvalds 40c043b077 Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  clockevents: Set noop handler in clockevents_exchange_device()
  tick-broadcast: Stop active broadcast device when replacing it
  clocksource: Fix bug with max_deferment margin calculation
  rtc: Fix some bugs that allowed accumulating time drift in suspend/resume
  rtc: Disable the alarm in the hardware
2011-12-05 16:53:43 -08:00
Rabin Vincent c0afabd3d5 rtc: Disable the alarm in the hardware
Currently, the RTC code does not disable the alarm in the hardware.

This means that after a sequence such as the one below (the files are in the
RTC sysfs), the box will boot up after 2 minutes even though we've
asked for the alarm to be turned off.

	# echo $((`cat since_epoch`)+120) > wakealarm
	# echo 0 > wakealarm
	# poweroff

Fix this by disabling the alarm when there are no timers to run.

Cc: stable@kernel.org
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
2011-11-22 19:25:43 -08:00
Paul Gortmaker 2113852b23 rtc: Add module.h to implicit users in drivers/rtc
The module.h was implicitly everywhere, but when we clean
that up, the implicit users will compile fail; fix them up
in advance.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-31 19:31:28 -04:00
Thomas Gleixner b830ac1d9a rtc: fix hrtimer deadlock
Ben reported a lockup related to rtc. The lockup happens due to:

CPU0                                        CPU1

rtc_irq_set_state()			    __run_hrtimer()
  spin_lock_irqsave(&rtc->irq_task_lock)    rtc_handle_legacy_irq();
					      spin_lock(&rtc->irq_task_lock);
  hrtimer_cancel()
    while (callback_running);

So the running callback never finishes as it's blocked on
rtc->irq_task_lock.

Use hrtimer_try_to_cancel() instead and drop rtc->irq_task_lock while
waiting for the callback.  Fix this for both rtc_irq_set_state() and
rtc_irq_set_freq().

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Ben Greear <greearb@candelatech.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-07-26 16:49:42 -07:00
Thomas Gleixner 431e2bcc37 rtc: limit frequency
Due to the hrtimer self rearming mode a user can DoS the machine simply
because it's starved by hrtimer events.

The RTC hrtimer is self rearming.  We really need to limit the frequency
to something sensible.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Ben Greear <greearb@candelatech.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-07-26 16:49:42 -07:00
Thomas Gleixner 2c4f57d12d rtc: handle errors correctly in rtc_irq_set_state()
The code checks the correctness of the parameters, but unconditionally
arms/disarms the hrtimer.

The result is that a random task might arm/disarm rtc timer and surprise
the real owner by either generating events or by stopping them.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Ben Greear <greearb@candelatech.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-07-26 16:49:41 -07:00
Thomas Gleixner 6e7a333eaa rtc: Limit RTC PIE frequency
The RTC pie hrtimer is self rearming. We really need to limit the
frequency to something sensible. Thus limit it to the 8192Hz max
value from the rtc man documentation

Cc: Willy Tarreau <w@1wt.eu>
Cc: stable@kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[jstultz: slightly reworked to use RTC_MAX_FREQ value]
Signed-off-by: John Stultz <john.stultz@linaro.org>
2011-07-26 14:50:01 -07:00
Thomas Gleixner 3c8bb90efb rtc: Fix hrtimer deadlock
Ben reported a lockup related to rtc. The lockup happens due to:

CPU0                                        CPU1

rtc_irq_set_state()			    __run_hrtimer()
  spin_lock_irqsave(&rtc->irq_task_lock)    rtc_handle_legacy_irq();
					      spin_lock(&rtc->irq_task_lock);
  hrtimer_cancel()
    while (callback_running);

So the running callback never finishes as it's blocked on
rtc->irq_task_lock.

Use hrtimer_try_to_cancel() instead and drop rtc->irq_task_lock while
waiting for the callback. Fix this for both rtc_irq_set_state() and
rtc_irq_set_freq().

Cc: stable@kernel.org
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
2011-07-26 14:49:59 -07:00
Thomas Gleixner 53cc2820ac rtc: Handle errors correctly in rtc_irq_set_state()
In rtc_irq_set_state, the code checks the correctness of the parameters,
but then goes on to unconditionally arms/disarms the hrtimer. Thus a
random task might arm/disarm rtc timer and surprise the real owner by
either generating events or by stopping them.

Cc: stable@kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
2011-07-26 14:49:57 -07:00
Mark Brown d576fe49ca rtc: Staticize non-exported __rtc_set_alarm()
It's not referenced outside this file so there's no need for it to be in
the global namespace and sparse warns about that.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
2011-06-01 19:29:40 -07:00
Thomas Gleixner 92f73a62a1 Merge branch 'fortglx/39/tip/timers/rtc' of git://git.linaro.org/people/jstultz/linux into timers/urgent 2011-04-13 01:54:09 +02:00
Lucas De Marchi 25985edced Fix common misspellings
Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-31 11:26:23 -03:00
John Stultz f6d5b33125 RTC: Fix early irqs caused by calling rtc_set_alarm too early
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 <tglx@linutronix.de>
CC: Alessandro Zummo <a.zummo@towertech.it>
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
2011-03-29 18:44:05 -07:00
John Stultz f44f7f96a2 RTC: Initialize kernel state from RTC
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 <broonie@opensource.wolfsonmicro.com>
CC: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Alessandro Zummo <a.zummo@towertech.it>
CC: rtc-linux@googlegroups.com
Reported-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
2011-03-09 11:22:50 -08:00
John Stultz 456d66ecd0 RTC: Re-enable UIE timer/polling emulation
This patch re-enables UIE timer/polling emulation for rtc devices
that do not support alarm irqs.

CC: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
CC: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
2011-02-17 14:59:42 -08:00
Uwe Kleine-König 516373b8b6 RTC: Release mutex in error path of rtc_alarm_irq_enable
On hardware that doesn't support alarm interrupts, rtc_alarm_irq_enable
could return without releasing the ops_lock mutex.

This was introduced in
	aa0be0f (RTC: Propagate error handling via rtc_timer_enqueue properly)

This patch corrects the issue by only returning once the mutex is
released.

[john.stultz: Reworded the commit log]

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
2011-02-17 14:59:22 -08:00
Marcelo Roberto Jimenez 83a06bf50b RTC: Prevents a division by zero in kernel code.
This patch prevents a user space program from calling the RTC_IRQP_SET
ioctl with a negative value of frequency. Also, if this call is make
with a zero value of frequency, there would be a division by zero in the
kernel code.

[jstultz: Also initialize irq_freq to 1 to catch other divbyzero issues]

CC: Alessandro Zummo <a.zummo@towertech.it>
CC: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
Signed-off-by: John Stultz <john.stultz@linaro.org>
2011-02-03 12:59:50 -08:00
John Stultz d5553a5561 RTC: Properly handle rtc_read_alarm error propagation and fix bug
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 <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
LKML-Reference: <1295565973-14358-2-git-send-email-john.stultz@linaro.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2011-01-21 17:38:19 +01:00
John Stultz aa0be0f465 RTC: Propagate error handling via rtc_timer_enqueue properly
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 <ddaney@caviumnetworks.com>
Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Diagnosed-by: David Daney <ddaney@caviumnetworks.com>
Tested-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
LKML-Reference: <1295565973-14358-1-git-send-email-john.stultz@linaro.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2011-01-21 17:38:19 +01:00