linux-stable.git/drivers/rtc/interface.c, branch linux-3.2.y

rtc: set the alarm to the next expiring timer

2018-02-13T18:32:08+00:00

commit 74717b28cb32e1ad3c1042cafd76b264c8c0f68d upstream.

If there is any non expired timer in the queue, the RTC alarm is never set.
This is an issue when adding a timer that expires before the next non
expired timer.

Ensure the RTC alarm is set in that case.

Fixes: 2b2f5ff00f63 ("rtc: interface: ignore expired timers when enqueuing new timers")
Signed-off-by: Alexandre Belloni 
[bwh: Backported to 3.2: open-code ktime_before()]
Signed-off-by: Ben Hutchings

rtc: interface: ignore expired timers when enqueuing new timers

2018-02-13T18:32:08+00:00

commit 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 upstream.

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 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Ben Hutchings

rtc: Provide flag for rtc devices that don't support UIE

2012-04-02T16:53:10+00:00

commit 4a649903f91232d02284d53724b0a45728111767 upstream.

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.

Reported-by: Richard Weinberger 
Tested-by: Richard Weinberger 
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

rtc: Disable the alarm in the hardware (v2)

2012-04-02T16:52:35+00:00

commit 41c7f7424259ff11009449f87c95656f69f9b186 upstream.

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: John Stultz 
Signed-off-by: Rabin Vincent 
[Merged in the second revision from Rabin]
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

drivers/rtc/interface.c: fix alarm rollover when day or month is out-of-range

2012-01-26T00:13:06+00:00

commit e74a8f2edb92cb690b467cea0ab652c509e9f624 upstream.

Commit f44f7f96a20a ("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 , 

Reported-by: leo weppelman 
Reported-by: "P. van Gaans" 
Signed-off-by: Ben Hutchings 
Signed-off-by: Jonathan Nieder 
Cc: Mark Brown 
Cc: Marcelo Roberto Jimenez 
Cc: Thomas Gleixner 
Cc: John Stultz 
Acked-by: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Revert "rtc: Expire alarms after the time is set."

2012-01-04T15:57:22+00:00

This reverts commit 93b2ec0128c431148b216b8f7337c1a52131ef03.

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 
Requested-by: Konrad Rzeszutek Wilk 
Requested-by: John Stultz 
Cc: Neil Brown 
Signed-off-by: Linus Torvalds

Revert "rtc: Disable the alarm in the hardware"

2012-01-04T01:32:13+00:00

This reverts commit c0afabd3d553c521e003779c127143ffde55a16f.

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  (Toshiba Tecra)
Reported-by: Antonio-M. Corbi Bellot  (Toshiba Portege R500)
Reported-by: Marco Santos  (Toshiba Portege Z830)
Reported-by: Christophe Vu-Brugier   (Toshiba Portege R830)
Cc: Jonathan Nieder 
Requested-by: John Stultz 
Cc: stable@kernel.org  # for the versions that applied this
Signed-off-by: Linus Torvalds

rtc: Expire alarms after the time is set.

2011-12-13T20:26:11+00:00

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 
[Also catch set_mmss case -jstultz]
Signed-off-by: John Stultz

Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2011-12-06T00:53:43+00:00

* '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

rtc: Disable the alarm in the hardware

2011-11-23T03:25:43+00:00

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 
Signed-off-by: Rabin Vincent 
Signed-off-by: John Stultz