linux/drivers/rtc/interface.c, branch v3.2-rc2

rtc: Add module.h to implicit users in drivers/rtc

2011-10-31T23:31:28Z

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

rtc: Limit RTC PIE frequency

2011-07-26T21:50:01Z

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 Cc: stable@kernel.org Signed-off-by: Thomas Gleixner [jstultz: slightly reworked to use RTC_MAX_FREQ value] Signed-off-by: John Stultz

rtc: Fix hrtimer deadlock

2011-07-26T21:49:59Z

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

rtc: Handle errors correctly in rtc_irq_set_state()

2011-07-26T21:49:57Z

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

rtc: Staticize non-exported __rtc_set_alarm()

2011-06-02T02:29:40Z

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:09Z

Fix common misspellings

2011-03-31T14:26:23Z

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:05Z

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:50Z

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:42Z

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