linux-toradex.git/drivers/rtc/interface.c, branch v3.0.3

rtc: limit frequency

2011-08-05T04:58:32+00:00

commit 431e2bcc371016824f419baa745f82388258f3ee upstream.

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 
Cc: John Stultz 
Cc: Ingo Molnar 
Cc: Ben Greear 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

rtc: fix hrtimer deadlock

2011-08-05T04:58:32+00:00

commit b830ac1d9a2262093bb0f3f6a2fd2a1c8278daf5 upstream.

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 
Reported-by: Ben Greear 
Cc: John Stultz 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

rtc: handle errors correctly in rtc_irq_set_state()

2011-08-05T04:58:32+00:00

commit 2c4f57d12df7696d65b0247bfd57fd082a7719e6 upstream.

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 
Cc: John Stultz 
Cc: Ingo Molnar 
Cc: Ben Greear 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

rtc: Staticize non-exported __rtc_set_alarm()

2011-06-02T02:29:40+00:00

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

Merge branch 'fortglx/39/tip/timers/rtc' of git://git.linaro.org/people/jstultz/linux into timers/urgent

2011-04-12T23:54:09+00:00

Fix common misspellings

2011-03-31T14:26:23+00:00

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi

RTC: Fix early irqs caused by calling rtc_set_alarm too early

2011-03-30T01:44:05+00:00

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 
CC: Alessandro Zummo 
Reported-by: Konrad Rzeszutek Wilk 
Tested-by: Konrad Rzeszutek Wilk 
Signed-off-by: John Stultz

RTC: Initialize kernel state from RTC

2011-03-09T19:22:50+00:00

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 
CC: Marcelo Roberto Jimenez 
CC: Thomas Gleixner 
CC: Alessandro Zummo 
CC: rtc-linux@googlegroups.com
Reported-by: Mark Brown 
Signed-off-by: John Stultz

RTC: Re-enable UIE timer/polling emulation

2011-02-17T22:59:42+00:00

This patch re-enables UIE timer/polling emulation for rtc devices
that do not support alarm irqs.

CC: Uwe Kleine-König 
CC: Thomas Gleixner 
Reported-by: Uwe Kleine-König 
Tested-by: Uwe Kleine-König 
Signed-off-by: John Stultz

RTC: Release mutex in error path of rtc_alarm_irq_enable

2011-02-17T22:59:22+00:00

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