drivers/rtc/interface.c: check the error after __rtc_read_time()

In __rtc_set_alarm(), the error after __rtc_read_time() is not checked.
If rtc device fail to read time, we cannot guarantee the foll

drivers/rtc/interface.c: check the error after __rtc_read_time()

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 <hyogi.gim@lge.com>
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>

show more ...

drivers/rtc/interface.c: fix infinite loop in initializing the alarm

In __rtc_read_alarm(), if the alarm time retrieved by
rtc_read_alarm_internal() from the device contains invalid values (e.g.
mon

drivers/rtc/interface.c: fix infinite loop in initializing the alarm

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 <alnovak@suse.cz>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Reported-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...

rtc: verify a critical argument to rtc_update_irq() before using it

This small addition to the core simplifies code in the drivers and makes
them more robust when handling shared IRQs.

Signed-off-b

rtc: verify a critical argument to rtc_update_irq() before using it

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 <a.zummo@towertech.it>
Cc: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...

rtc: Keep system awake until all expired RTC timers are handled

Current implementation of RTC interface allows for system suspend to
occur in the following cases:
(a) if a timer is set in the past a

rtc: Keep system awake until all expired RTC timers are handled

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 <a.zummo@towertech.it>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Arve Hjonnevag <arve@android.com>
Cc: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>

show more ...

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

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 imme

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

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 <chris.brand@broadcom.com>
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>

show more ...

drivers/rtc/interface.c: fix checkpatch errors

Fixes the following types of errors:
ERROR: "foo* bar" should be "foo *bar"
ERROR: else should follow close brace '}'
WARNING: braces {} are not

drivers/rtc/interface.c: fix checkpatch errors

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 <sachin.kamat@linaro.org>
Cc: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...

driver-core: constify data for class_find_device()

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/

driver-core: constify data for class_find_device()

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>

show more ...

RTC: Avoid races between RTC alarm wakeup and suspend.

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 m

RTC: Avoid races between RTC alarm wakeup and suspend.

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>

show more ...

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

Richard Weinberger noticed that on some RTC hardware that
doesn't support UIE mode, due to coarse granular alarms
(like 1minute resolution),

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

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>

show more ...

rtc: Disable the alarm in the hardware (v2)

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 sysf

rtc: Disable the alarm in the hardware (v2)

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>

show more ...

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

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

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

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>

show more ...

rtc: Avoid setting alarm to a time in the past

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 en

rtc: Avoid setting alarm to a time in the past

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>

show more ...

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

Commit f44f7f96a20a ("RTC: Initialize kernel state from RTC") introduced a
potential infinite loop. If an alarm time co

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

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>

show more ...

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

This reverts commit 93b2ec0128c431148b216b8f7337c1a52131ef03.

The call to "schedule_work()" in rtc_initialize_alarm() happens too
early, and can c

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

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>

show more ...

Revert "rtc: Disable the alarm in the hardware"

This reverts commit c0afabd3d553c521e003779c127143ffde55a16f.

It causes failures on Toshiba laptops - instead of disabling the alarm,
it actually see

Revert "rtc: Disable the alarm in the hardware"

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>

show more ...

rtc: Expire alarms after the time is set.

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

rtc: Expire alarms after the time is set.

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>

show more ...

rtc: Disable the alarm in the hardware

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), t

rtc: Disable the alarm in the hardware

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>

show more ...

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

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: Pa

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

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>

show more ...

rtc: Fix RTC PIE frequency limit

Thomas earlier submitted a fix to limit the RTC PIE freq, but
picked 5000Hz out of the air. Willy noticed that we should
instead use the 8192Hz max from the rtc man

rtc: Fix RTC PIE frequency limit

Thomas earlier submitted a fix to limit the RTC PIE freq, but
picked 5000Hz out of the air. Willy noticed that we should
instead use the 8192Hz max from the rtc man documentation.

Cc: Willy Tarreau <w@1wt.eu>
Cc: stable@kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>

show more ...

rtc: fix hrtimer deadlock

Ben reported a lockup related to rtc. The lockup happens due to:

CPU0 CPU1

rtc_irq_set_state() __run_hrtimer()
spin_lock_ir

rtc: fix hrtimer deadlock

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>

show more ...

rtc: limit frequency

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 f

rtc: limit frequency

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>

show more ...

rtc: handle errors correctly in rtc_irq_set_state()

The code checks the correctness of the parameters, but unconditionally
arms/disarms the hrtimer.

The result is that a random task might arm/disar

rtc: handle errors correctly in rtc_irq_set_state()

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>

show more ...

rtc: Limit RTC PIE frequency

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

rtc: Limit RTC PIE frequency

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>

show more ...

rtc: Fix hrtimer deadlock

Ben reported a lockup related to rtc. The lockup happens due to:

CPU0 CPU1

rtc_irq_set_state() __run_hrtimer()
spin_lock_ir

rtc: Fix hrtimer deadlock

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>

show more ...

rtc: Handle errors correctly in rtc_irq_set_state()

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
rand

rtc: Handle errors correctly in rtc_irq_set_state()

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>

show more ...