aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/rtc/interface.c
Commit message (Collapse)AuthorAgeFilesLines
...
* rtc: Update interface.c to use y2038-safe time interfacesXunlei Pang2015-01-241-12/+10
| | | | | | | | | | | | | 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 <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Signed-off-by: Xunlei Pang <[email protected]> Signed-off-by: John Stultz <[email protected]>
* rtc: refine rtc_timer_do_work() to consider other set alarm failuresXunlei Pang2014-12-111-0/+13
| | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Cc: Alessandro Zummo <[email protected]> Cc: John Stultz <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* drivers/rtc/interface.c: check the validation of rtc_time in __rtc_read_timeHyogi Gim2014-12-111-0/+8
| | | | | | | | | | | | | | | 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 <[email protected]> Cc: Alessandro Zummo <[email protected]> Cc: John Stultz <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* drivers/rtc/interface.c: check the error after __rtc_read_time()Hyogi Gim2014-08-081-0/+2
| | | | | | | | | | | | | 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 <[email protected]> Acked-by: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* drivers/rtc/interface.c: fix infinite loop in initializing the alarmAles Novak2014-06-061-2/+12
| | | | | | | | | | | | | | | | 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 <[email protected]> Acked-by: Alessandro Zummo <[email protected]> Reported-by: Jiri Bohac <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* rtc: verify a critical argument to rtc_update_irq() before using itAlessandro Zummo2014-04-031-0/+3
| | | | | | | | | | 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 <[email protected]> Cc: Alexander Shiyan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* rtc: Keep system awake until all expired RTC timers are handledZoran Markovic2013-07-221-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Cc: John Stultz <[email protected]> Cc: Arve Hjonnevag <[email protected]> Cc: Todd Poynor <[email protected]> Signed-off-by: Zoran Markovic <[email protected]> Signed-off-by: John Stultz <[email protected]>
* drivers/rtc/interface.c: return -EBUSY, not -EACCES when device is busyChris Brand2013-07-031-4/+4
| | | | | | | | | | | 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 <[email protected]> Acked-by: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* drivers/rtc/interface.c: fix checkpatch errorsSachin Kamat2013-07-031-9/+9
| | | | | | | | | | | | 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 <[email protected]> Cc: Jingoo Han <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* 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 <[email protected]> Acked-by: Grant Likely <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
* 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 <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
* 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: [email protected] Reported-by: Richard Weinberger <[email protected]> Tested-by: Richard Weinberger <[email protected]> Signed-off-by: John Stultz <[email protected]>
* 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: [email protected] Cc: John Stultz <[email protected]> Signed-off-by: Rabin Vincent <[email protected]> [Merged in the second revision from Rabin] Signed-off-by: John Stultz <[email protected]>
* 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 <[email protected]> Signed-off-by: NeilBrown <[email protected]> [Remove problematic initialization change, update commit log, also catch set_mmss case -jstultz] Signed-off-by: John Stultz <[email protected]>
* 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 <[email protected]> Tested-by: NeilBrown <[email protected]> Tested-by: Sander Eikelenboom <[email protected]> Signed-off-by: John Stultz <[email protected]>
* 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 <[email protected]> Reported-by: "P. van Gaans" <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: Jonathan Nieder <[email protected]> Cc: Mark Brown <[email protected]> Cc: Marcelo Roberto Jimenez <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: John Stultz <[email protected]> Acked-by: Alessandro Zummo <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* 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 <[email protected]> Requested-by: Konrad Rzeszutek Wilk <[email protected]> Requested-by: John Stultz <[email protected]> Cc: Neil Brown <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* 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 <[email protected]> (Toshiba Tecra) Reported-by: Antonio-M. Corbi Bellot <[email protected]> (Toshiba Portege R500) Reported-by: Marco Santos <[email protected]> (Toshiba Portege Z830) Reported-by: Christophe Vu-Brugier <[email protected]> (Toshiba Portege R830) Cc: Jonathan Nieder <[email protected]> Requested-by: John Stultz <[email protected]> Cc: [email protected] # for the versions that applied this Signed-off-by: Linus Torvalds <[email protected]>
* 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: [email protected] Signed-off-by: NeilBrown <[email protected]> [Also catch set_mmss case -jstultz] Signed-off-by: John Stultz <[email protected]>
* 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: [email protected] Cc: John Stultz <[email protected]> Signed-off-by: Rabin Vincent <[email protected]> Signed-off-by: John Stultz <[email protected]>
| * 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(). Signed-off-by: Thomas Gleixner <[email protected]> Reported-by: Ben Greear <[email protected]> Cc: John Stultz <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
| * rtc: limit frequencyThomas Gleixner2011-07-261-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 <[email protected]> Cc: John Stultz <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Ben Greear <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
| * rtc: handle errors correctly in rtc_irq_set_state()Thomas Gleixner2011-07-261-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 <[email protected]> Cc: John Stultz <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Ben Greear <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* | rtc: Add module.h to implicit users in drivers/rtcPaul Gortmaker2011-10-311-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 <[email protected]>
* | 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 <[email protected]> Cc: [email protected] Signed-off-by: Thomas Gleixner <[email protected]> [jstultz: slightly reworked to use RTC_MAX_FREQ value] Signed-off-by: John Stultz <[email protected]>
* | 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: [email protected] Reported-by: Ben Greear <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: John Stultz <[email protected]>
* | 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: [email protected] Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: John Stultz <[email protected]>
* 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 <[email protected]> Signed-off-by: John Stultz <[email protected]>
* Merge branch 'fortglx/39/tip/timers/rtc' of ↵Thomas Gleixner2011-04-121-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 <[email protected]> CC: Alessandro Zummo <[email protected]> Reported-by: Konrad Rzeszutek Wilk <[email protected]> Tested-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: John Stultz <[email protected]>
* | Fix common misspellingsLucas De Marchi2011-03-311-1/+1
|/ | | | | | Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <[email protected]>
* 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 <[email protected]> CC: Marcelo Roberto Jimenez <[email protected]> CC: Thomas Gleixner <[email protected]> CC: Alessandro Zummo <[email protected]> CC: [email protected] Reported-by: Mark Brown <[email protected]> Signed-off-by: John Stultz <[email protected]>
* 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 <[email protected]> CC: Thomas Gleixner <[email protected]> Reported-by: Uwe Kleine-König <[email protected]> Tested-by: Uwe Kleine-König <[email protected]> Signed-off-by: John Stultz <[email protected]>
* 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 <[email protected]> Signed-off-by: John Stultz <[email protected]>
* 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 <[email protected]> CC: Thomas Gleixner <[email protected]> Signed-off-by: Marcelo Roberto Jimenez <[email protected]> Signed-off-by: John Stultz <[email protected]>
* 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 <[email protected]> Signed-off-by: John Stultz <[email protected]> LKML-Reference: <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
* 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 <[email protected]> Reported-by: Andreas Schwab <[email protected]> Reported-by: Geert Uytterhoeven <[email protected]> Diagnosed-by: David Daney <[email protected]> Tested-by: David Daney <[email protected]> Signed-off-by: John Stultz <[email protected]> LKML-Reference: <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
* 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 <[email protected]> Cc: John Stultz <[email protected]>
* RTC: Rework RTC code to use timerqueue for eventsJohn Stultz2010-12-111-224/+348
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> LKML Reference: <[email protected]> Acked-by: Alessandro Zummo <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> CC: Alessandro Zummo <[email protected]> CC: Thomas Gleixner <[email protected]> CC: Richard Cochran <[email protected]>
* 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 <[email protected]>
* rtc: make rtc_update_irq callable with irqs enabledAtsushi Nemoto2009-06-191-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 <[email protected]> Cc: Alessandro Zummo <[email protected]> Cc: David Brownell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* rtc: use set_mmss when set_time is not availableAlessandro Zummo2009-01-061-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 <[email protected]> Cc: Kumar Gala <[email protected]> Cc: David Brownell <[email protected]> Cc: Lennert Buytenhek <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* rtc: move power of 2 periodic frequency check down into driversJonathan Cameron2009-01-061-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 <[email protected]> Signed-off-by: Alessandro Zummo <[email protected]> Cc: David Brownell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* rtc: struct device: replace bus_id with dev_name(), dev_set_name()Kay Sievers2009-01-061-1/+1
| | | | | | | | | Acked-by: Alessandro Zummo <[email protected]> Acked-By: Greg Kroah-Hartman <[email protected]> Signed-off-by: Kay Sievers <[email protected]> Cc: David Brownell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* 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 <[email protected]> Cc: David Brownell <[email protected]> Cc: Atsushi Nemoto <[email protected]> Cc: Ralf Baechle <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* rtc: fix handling of missing tm_year data when reading alarmsMark Brown2008-11-061-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 <[email protected]> Acked-by: Alessandro Zummo <[email protected]> Cc: David Brownell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* 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 <[email protected]> Acked-by: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* 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 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
* 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 <[email protected]> Cc: Mark Lord <[email protected]> Acked-by: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
generated by cgit (git 2.51.2) at 2025-12-03 18:06:46 +0000