user/sven/linux.git/drivers/rtc/interface.c, branch v3.11.2

drivers/rtc/interface.c: return -EBUSY, not -EACCES when device is busy

2013-07-03T23:08:00Z

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 Acked-by: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

drivers/rtc/interface.c: fix checkpatch errors

2013-07-03T23:07:46Z

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 Cc: Jingoo Han Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

driver-core: constify data for class_find_device()

2013-02-06T20:18:56Z

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 Acked-by: Grant Likely Signed-off-by: Greg Kroah-Hartman

RTC: Avoid races between RTC alarm wakeup and suspend.

2012-08-08T18:49:16Z

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 Signed-off-by: Rafael J. Wysocki

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

2012-03-16T01:23:10Z

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

rtc: Disable the alarm in the hardware (v2)

2012-01-27T03:41:42Z

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

rtc: Expire alarms after the time is set. (v2)

2012-01-27T03:41:36Z

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 Signed-off-by: NeilBrown [Remove problematic initialization change, update commit log, also catch set_mmss case -jstultz] Signed-off-by: John Stultz

rtc: Avoid setting alarm to a time in the past

2012-01-27T03:41:30Z

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 Tested-by: NeilBrown Tested-by: Sander Eikelenboom Signed-off-by: John Stultz

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

2012-01-11T00:30:53Z

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 Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

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

2012-01-04T15:57:22Z

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