summaryrefslogtreecommitdiffstats
path: root/drivers/rtc/interface.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* driver-core: constify data for class_find_device()Michał Mirosław2013-02-061-3/+3
| | | | | | | | | | | | | | | | | | 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>
* RTC: Avoid races between RTC alarm wakeup and suspend.NeilBrown2012-08-081-0/+2
| | | | | | | | | | | | | | | | | | 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>
* rtc: Provide flag for rtc devices that don't support UIEJohn Stultz2012-03-161-0/+5
| | | | | | | | | | | | | | | | | | | 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>
* rtc: Disable the alarm in the hardware (v2)Rabin Vincent2012-01-271-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* rtc: Expire alarms after the time is set. (v2)NeilBrown2012-01-271-0/+4
| | | | | | | | | | | | | | | | | | | | | 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>
* rtc: Avoid setting alarm to a time in the pastJohn Stultz2012-01-271-1/+10
| | | | | | | | | | | | | | | | 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>
* drivers/rtc/interface.c: fix alarm rollover when day or month is out-of-rangeBen Hutchings2012-01-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | 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 <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>
* Revert "rtc: Expire alarms after the time is set."Linus Torvalds2012-01-041-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <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>
* Revert "rtc: Disable the alarm in the hardware"Linus Torvalds2012-01-041-34/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <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>
* rtc: Expire alarms after the time is set.NeilBrown2011-12-131-0/+6
| | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'timers-urgent-for-linus' of ↵Linus Torvalds2011-12-061-10/+34
|\ | | | | | | | | | | | | | | | | | | | | 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
| * rtc: Disable the alarm in the hardwareRabin Vincent2011-11-231-10/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * rtc: fix hrtimer deadlockThomas Gleixner2011-07-271-19/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * rtc: limit frequencyThomas Gleixner2011-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * rtc: handle errors correctly in rtc_irq_set_state()Thomas Gleixner2011-07-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | rtc: Add module.h to implicit users in drivers/rtcPaul Gortmaker2011-11-011-0/+1
| | | | | | | | | | | | | | | | 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>
* | rtc: Limit RTC PIE frequencyThomas Gleixner2011-07-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | rtc: Fix hrtimer deadlockThomas Gleixner2011-07-261-19/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | rtc: Handle errors correctly in rtc_irq_set_state()Thomas Gleixner2011-07-261-0/+3
|/ | | | | | | | | | | 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>
* rtc: Staticize non-exported __rtc_set_alarm()Mark Brown2011-06-021-1/+1
| | | | | | | | 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>
* Merge branch 'fortglx/39/tip/timers/rtc' of ↵Thomas Gleixner2011-04-131-0/+26
|\ | | | | | | git://git.linaro.org/people/jstultz/linux into timers/urgent
| * RTC: Fix early irqs caused by calling rtc_set_alarm too earlyJohn Stultz2011-03-301-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Fix common misspellingsLucas De Marchi2011-03-311-1/+1
|/ | | | | | Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
* RTC: Initialize kernel state from RTCJohn Stultz2011-03-091-0/+180
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* RTC: Re-enable UIE timer/polling emulationJohn Stultz2011-02-171-1/+17
| | | | | | | | | | | 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>
* RTC: Release mutex in error path of rtc_alarm_irq_enableUwe Kleine-König2011-02-171-3/+2
| | | | | | | | | | | | | | | | 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>
* RTC: Prevents a division by zero in kernel code.Marcelo Roberto Jimenez2011-02-031-0/+3
| | | | | | | | | | | | | | 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>
* RTC: Properly handle rtc_read_alarm error propagation and fix bugJohn Stultz2011-01-211-3/+9
| | | | | | | | | | | | | | 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>
* RTC: Propagate error handling via rtc_timer_enqueue properlyJohn Stultz2011-01-211-21/+28
| | | | | | | | | | | | | | | | | | | | | 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>
* rtc: Namespace fixupThomas Gleixner2010-12-131-21/+21
| | | | | | | | | rtctimer_* is already occupied by sound/core/rtctimer.c. Instead of fiddling with that, rename the new functions to rtc_timer_* which reads nicer anyway. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: John Stultz <johnstul@us.ibm.com>
* RTC: Rework RTC code to use timerqueue for eventsJohn Stultz2010-12-111-225/+349
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch reworks a large portion of the generic RTC code to in-effect virtualize the rtc interrupt code. The current RTC interface is very much a raw hardware interface. Via the proc, /dev/, or sysfs interfaces, applciations can set the hardware to trigger interrupts in one of three modes: AIE: Alarm interrupt UIE: Update interrupt (ie: once per second) PIE: Periodic interrupt (sub-second irqs) The problem with this interface is that it limits the RTC hardware so it can only be used by one application at a time. The purpose of this patch is to extend the RTC code so that we can multiplex multiple applications event needs onto a single RTC device. This is done by utilizing the timerqueue infrastructure to manage a list of events, which cause the RTC hardware to be programmed to fire an interrupt for the next event in the list. In order to preserve the functionality of the exsting proc,/dev/ and sysfs interfaces, we emulate the different interrupt modes as follows: AIE: We create a rtc_timer dedicated to AIE mode interrupts. There is only one per device, so we don't change existing interface semantics. UIE: Again, a dedicated rtc_timer, set for periodic mode, is used to emulate UIE interrupts. Again, only one per device. PIE: Since PIE mode interrupts fire faster then the RTC's clock read granularity, we emulate PIE mode interrupts using a hrtimer. Again, one per device. With this patch, the rtctest.c application in Documentation/rtc.txt passes fine on x86 hardware. However, there may very well still be bugs, so greatly I'd appreciate any feedback or testing! Signed-off-by: John Stultz <john.stultz@linaro.org> LKML Reference: <1290136329-18291-4-git-send-email-john.stultz@linaro.org> Acked-by: Alessandro Zummo <a.zummo@towertech.it> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> CC: Alessandro Zummo <a.zummo@towertech.it> CC: Thomas Gleixner <tglx@linutronix.de> CC: Richard Cochran <richardcochran@gmail.com>
* headers: remove sched.h from interrupt.hAlexey Dobriyan2009-10-111-0/+1
| | | | | | | | After m68k's task_thread_info() doesn't refer to current, it's possible to remove sched.h from interrupt.h and not break m68k! Many thanks to Heiko Carstens for allowing this. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
* rtc: make rtc_update_irq callable with irqs enabledAtsushi Nemoto2009-06-201-5/+7
| | | | | | | | | | | | | | | The rtc_update_irq() might be called with irqs enabled, if a interrupt handler was registered without IRQF_DISABLED. Use spin_lock_irqsave/spin_unlock_irqrestore instead of spin_lock/spin_unlock. Also update kerneldoc and drivers which do extra work to follow the current interface spec, as suggestted by David Brownell. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* rtc: use set_mmss when set_time is not availableAlessandro Zummo2009-01-071-3/+8
| | | | | | | | | | | | | Drivers should only need to implement either set_mmss (counter based RTCs) or set_time (most RTCs). The RTC subsystem will handle them appropriately. Signed-off-by: Alessandro Zummo <a.zummo@towertech.it> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: David Brownell <david-b@pacbell.net> Cc: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* rtc: move power of 2 periodic frequency check down into driversJonathan Cameron2009-01-071-3/+0
| | | | | | | | | | | | | Move the power of 2 check on frequencies down into individual rtc drivers This is to allow for non power of 2 real time clock periodic interrupts such as those on the pxa27x to be found in the new pxa27x-rtc driver Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Alessandro Zummo <a.zummo@towertech.it> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* rtc: struct device: replace bus_id with dev_name(), dev_set_name()Kay Sievers2009-01-071-1/+1
| | | | | | | | | Acked-by: Alessandro Zummo <a.zummo@towertech.it> Acked-By: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* rtc: add alarm/update irq interfacesAlessandro Zummo2009-01-041-0/+54
| | | | | | | | | | | | | | | | Add standard interfaces for alarm/update irqs enabling. Drivers are no more required to implement equivalent ioctl code as rtc-dev will provide it. UIE emulation should now be handled correctly and will work even for those RTC drivers who cannot be configured to do both UIE and AIE. Signed-off-by: Alessandro Zummo <a.zummo@towertech.it> Cc: David Brownell <david-b@pacbell.net> Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* rtc: fix handling of missing tm_year data when reading alarmsMark Brown2008-11-071-1/+1
| | | | | | | | | | | | When fixing up invalid years rtc_read_alarm() was calling rtc_valid_tm() as a boolean but rtc_valid_tm() returns zero on success or a negative number if the time is not valid so the test was inverted. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Alessandro Zummo <a.zummo@towertech.it> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* rtc: don't return -EBUSY when mutex_lock_interruptible() failsDavid Brownell2008-07-301-5/+5
| | | | | | | | | | | It was pointed out that the RTC framework handles its mutex locks oddly ... returning -EBUSY when interrupted. This fixes that by returning the value of mutex_lock_interruptible() (i.e. -EINTR). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> 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>
* Driver Core: add ability for class_find_device to start in middle of listGreg Kroah-Hartman2008-07-221-1/+1
| | | | | | | | | | | | | | | This mirrors the functionality that driver_find_device has as well. We add a start variable, and all callers of the function are fixed up at the same time. The block layer will be using this new functionality in a follow-on patch. Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* rtc: rtc_read_alarm() handles wraparoundDavid Brownell2008-07-041-11/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While 0e36a9a4a788e4e92407774df76c545910810d35 ("rtc: fix readback from /sys/class/rtc/rtc?/wakealarm") made sure that active alarms were never returned with invalid "wildcard" fields (negative), it can still report (wrongly) that the alarm triggers in the past. Example, if it's now 10am, an alarm firing at 5am will be triggered TOMORROW not today. (Which may also be next month or next year...) This updates that alarm handling in three ways: * Handle alarm rollover in the common cases of RTCs that don't support matching on all date fields. * Skip the invalid-field logic when it's not needed. * Minor bugfix ... tm_isdst should be ignored, it's one of the fields Linux doesn't maintain. A warning is emitted for some of the unhandled rollover cases, but the possible combinations are a bit too numerous to handle every bit of potential hardware and firmware braindamage. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Mark Lord <lkml@rtr.ca> 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>
* rtc: use class iteration apiDave Young2008-01-251-10/+12
| | | | | | | | | | Convert to use the class iteration api. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* RTC: assure proper memory ordering with respect to RTC_DEV_BUSY flagJiri Kosina2007-12-051-2/+2
| | | | | | | | | | | | | | | We must make sure that the RTC_DEV_BUSY flag has proper lock semantics, i.e. that the RTC_DEV_BUSY stores clearing the flag don't get reordered before the preceeding stores and loads and vice versa. Spotted by Nick Piggin. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: David Brownell <david-b@pacbell.net> 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>
* RTC: convert mutex to bitfieldJiri Kosina2007-11-291-2/+2
| | | | | | | | | | | | | | RTC code is using mutex to assure exclusive access to /dev/rtc. This is however wrong usage, as it leaves the mutex locked when returning into userspace, which is unacceptable. Convert rtc->char_lock into bit operation. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Alessandro Zummo <a.zummo@towertech.it> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* rtc: fix readback from /sys/class/rtc/rtc?/wakealarmMark Lord2007-10-161-1/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix readback of RTC alarms on platforms which return -1 in non-hardware-supported RTC alarm fields. To fill in the missing (-1) values, we grab an RTC timestamp along with the RTC alarm value, and use the timestamp fields to populate the missing alarm fields. To counter field-wrap races (since the timestamp and alarm are not read together atomically), we read the RTC timestamp both before and after reading the RTC alarm value, and then check for wrapped fields --> if any have wrapped, we know we have a possible inconsistency, so we loop and reread the timestamp and alarm again. Wrapped fields in the RTC timestamps are an issue because rtc-cmos.c, for example, also gets/uses an RTC timestamp internally while fetching the RTC alarm. If our timestamp here wasn't the same (minutes and higher) as what was used internally there, then we might end up populating the -1 fields with inconsistent values. This fixes readbacks from /sys/class/rtc/rtc?/wakealarm, as well as other code paths which call rtc_read_alarm(). Signed-off-by: Mark Lord <mlord@pobox.com> Cc: David Brownell <david-b@pacbell.net> 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>
* rtc_irq_set_freq() requires power-of-two and associated kerneldocDavid Brownell2007-10-161-0/+24
| | | | | | | | | | | | | RTC periodic IRQs are only defined to work for 2^N Hz values. This patch moves that validity check into the infrastructure, so drivers don't need to check it; and adds kerneldoc for the two interface functions related to periodic IRQs. (One of which was quite mysterious until its first use was recently checked in!) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> 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>
* RTC: periodic irq fixAlessandro Zummo2007-10-161-3/+12
| | | | | | | | | | | | Add kernel/kernel and kernel/user locking for the periodic irq feature of the rtc class. PIE ioctls are also supported. Signed-off-by: Alessandro Zummo <a.zummo@towertech.it> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* rtc: remove "RTC_ALM_SET mode" bugsDavid Brownell2007-05-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a common glitch in how RTC drivers handle two "set alarm" modes, by getting rid of the surprising/hidden one that was rarely implemented correctly (and which could expose nonportable hardware-specific behavior). The glitch comes from the /dev/rtcX logic implementing the legacy RTC_ALM_SET (limited to 24 hours, needing RTC_AIE_ON) ioctl on top of the RTC driver call providing access to the newer RTC_WKALM_SET (without those limitations) by initializing the day/month/year fields to be invalid ... that second mode. Now, since few RTC drivers check those fields, and most hardware misbehaves when faced with invalid date fields, many RTC drivers will set bogus alarm times on those RTC_ALM_SET code paths. (Several in-tree drivers have that issue, and I also noticed it with code reviews on several new RTC drivers.) This patch ensures that RTC drivers never see such invalid alarm fields, by moving some logic out of rtc-omap into the RTC_ALM_SET code and adding an explicit check (which will prevent the issue on other code paths). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Scott Wood <scottwood@freescale.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>
* rtc: remove rest of class_deviceDavid Brownell2007-05-081-17/+17
| | | | | | | | | | Finish converting the RTC framework so it no longer uses class_device. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> 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>
* rtc: rtc interfaces don't use class_deviceDavid Brownell2007-05-081-42/+36
| | | | | | | | | | | | This patch removes class_device from the programming interface that the RTC framework exposes to the rest of the kernel. Now an rtc_device is passed, which is more type-safe and streamlines all the relevant code. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> 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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 11:25:28 +0100