11 Jan, 2012
1 commit
-
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
04 Jan, 2012
2 commits
-
This reverts commit 93b2ec0128c431148b216b8f7337c1a52131ef03.
The call to "schedule_work()" in rtc_initialize_alarm() happens too
early, and can cause oopses at bootupNeil 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 -
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 (Toshiba Tecra)
Reported-by: Antonio-M. Corbi Bellot (Toshiba Portege R500)
Reported-by: Marco Santos (Toshiba Portege Z830)
Reported-by: Christophe Vu-Brugier (Toshiba Portege R830)
Cc: Jonathan Nieder
Requested-by: John Stultz
Cc: stable@kernel.org # for the versions that applied this
Signed-off-by: Linus Torvalds
14 Dec, 2011
1 commit
-
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
[Also catch set_mmss case -jstultz]
Signed-off-by: John Stultz
06 Dec, 2011
1 commit
-
* '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
23 Nov, 2011
1 commit
-
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
# poweroffFix this by disabling the alarm when there are no timers to run.
Cc: stable@kernel.org
Cc: John Stultz
Signed-off-by: Rabin Vincent
Signed-off-by: John Stultz
01 Nov, 2011
1 commit
-
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
27 Jul, 2011
6 commits
-
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
Reported-by: Ben Greear
Cc: John Stultz
Cc: Ingo Molnar
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Cc: John Stultz
Cc: Ingo Molnar
Cc: Ben Greear
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Cc: John Stultz
Cc: Ingo Molnar
Cc: Ben Greear
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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 documentationCc: Willy Tarreau
Cc: stable@kernel.org
Signed-off-by: Thomas Gleixner
[jstultz: slightly reworked to use RTC_MAX_FREQ value]
Signed-off-by: John Stultz -
Ben reported a lockup related to rtc. The lockup happens due to:
CPU0 CPU1
rtc_irq_set_state() __run_hrtimer()
spin_lock_irqsave(&rtc->irq_task_lock) rtc_handle_legacy_irq();
spin_lock(&rtc->irq_task_lock);
hrtimer_cancel()
while (callback_running);So the running callback never finishes as it's blocked on
rtc->irq_task_lock.Use hrtimer_try_to_cancel() instead and drop rtc->irq_task_lock while
waiting for the callback. Fix this for both rtc_irq_set_state() and
rtc_irq_set_freq().Cc: stable@kernel.org
Reported-by: Ben Greear
Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz -
In rtc_irq_set_state, the code checks the correctness of the parameters,
but then goes on to unconditionally arms/disarms the hrtimer. Thus a
random task might arm/disarm rtc timer and surprise the real owner by
either generating events or by stopping them.Cc: stable@kernel.org
Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz
02 Jun, 2011
1 commit
-
It's not referenced outside this file so there's no need for it to be in
the global namespace and sparse warns about that.Signed-off-by: Mark Brown
Signed-off-by: John Stultz
13 Apr, 2011
1 commit
-
…linux into timers/urgent
31 Mar, 2011
1 commit
-
Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: Lucas De Marchi
30 Mar, 2011
1 commit
-
When we register an rtc device at boot, we read the alarm value
in hardware and set the rtc device's aie_timer to that value.The initial method to do this was to simply call rtc_set_alarm()
with the value read from hardware. However, this may cause problems
as rtc_set_alarm may enable interupts, and the RTC alarm might fire,
which can cause invalid pointer dereferencing since the RTC registration
is not complete.This patch solves the issue by initializing the rtc_device.aie_timer
y hand via rtc_initialize_alarm(). This avoids any calls to the RTC
hardware which might enable interrupts too early.CC: Thomas Gleixner
CC: Alessandro Zummo
Reported-by: Konrad Rzeszutek Wilk
Tested-by: Konrad Rzeszutek Wilk
Signed-off-by: John Stultz
10 Mar, 2011
1 commit
-
Mark Brown pointed out a corner case: that RTC alarms should
be allowed to be persistent across reboots if the hardware
supported it.The rework of the generic layer to virtualize the RTC alarm
virtualized much of the alarm handling, and removed the
code used to read the alarm time from the hardware.Mark noted if we want the alarm to be persistent across
reboots, we need to re-read the alarm value into the
virtualized generic layer at boot up, so that the generic
layer properly exposes that value.This patch restores much of the earlier removed
rtc_read_alarm code and wires it in so that we
set the kernel's alarm value to what we find in the
hardware at boot time.NOTE: Not all hardware supports persistent RTC alarm state across
system reset. rtc-cmos for example will keep the alarm time, but
disables the AIE mode irq. Applications should not expect the RTC
alarm to be valid after a system reset. We will preserve what
we can, to represent the hardware state at boot, but its not
guarenteed.Further, in the future, with multiplexed RTC alarms, the
soonest alarm to fire may not be the one set via the /dev/rt
ioctls. So an application may set the alarm with RTC_ALM_SET,
but after a reset find that RTC_ALM_READ returns an earlier
time. Again, we preserve what we can, but applications should
not expect the RTC alarm state to persist across a system reset.Big thanks to Mark for pointing out the issue!
Thanks also to Marcelo for helping think through the solution.CC: Mark Brown
CC: Marcelo Roberto Jimenez
CC: Thomas Gleixner
CC: Alessandro Zummo
CC: rtc-linux@googlegroups.com
Reported-by: Mark Brown
Signed-off-by: John Stultz
18 Feb, 2011
2 commits
-
This patch re-enables UIE timer/polling emulation for rtc devices
that do not support alarm irqs.CC: Uwe Kleine-König
CC: Thomas Gleixner
Reported-by: Uwe Kleine-König
Tested-by: Uwe Kleine-König
Signed-off-by: John Stultz -
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
Signed-off-by: John Stultz
04 Feb, 2011
1 commit
-
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
CC: Thomas Gleixner
Signed-off-by: Marcelo Roberto Jimenez
Signed-off-by: John Stultz
22 Jan, 2011
2 commits
-
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
Signed-off-by: John Stultz
LKML-Reference:
Signed-off-by: Thomas Gleixner -
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
Reported-by: Andreas Schwab
Reported-by: Geert Uytterhoeven
Diagnosed-by: David Daney
Tested-by: David Daney
Signed-off-by: John Stultz
LKML-Reference:
Signed-off-by: Thomas Gleixner
14 Dec, 2010
1 commit
-
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
Cc: John Stultz
11 Dec, 2010
1 commit
-
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
LKML Reference:
Acked-by: Alessandro Zummo
Reviewed-by: Thomas Gleixner
CC: Alessandro Zummo
CC: Thomas Gleixner
CC: Richard Cochran
12 Oct, 2009
1 commit
-
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
20 Jun, 2009
1 commit
-
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
Cc: Alessandro Zummo
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Jan, 2009
3 commits
-
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
Cc: Kumar Gala
Cc: David Brownell
Cc: Lennert Buytenhek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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 driverSigned-off-by: Jonathan Cameron
Signed-off-by: Alessandro Zummo
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Acked-by: Alessandro Zummo
Acked-By: Greg Kroah-Hartman
Signed-off-by: Kay Sievers
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
05 Jan, 2009
1 commit
-
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
Cc: David Brownell
Cc: Atsushi Nemoto
Cc: Ralf Baechle
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Nov, 2008
1 commit
-
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
Acked-by: Alessandro Zummo
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
31 Jul, 2008
1 commit
-
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
Acked-by: Alessandro Zummo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
22 Jul, 2008
1 commit
-
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
Signed-off-by: Greg Kroah-Hartman
05 Jul, 2008
1 commit
-
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
Cc: Mark Lord
Acked-by: Alessandro Zummo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
25 Jan, 2008
1 commit
-
Convert to use the class iteration api.
Signed-off-by: Dave Young
Cc: Alessandro Zummo
Signed-off-by: Greg Kroah-Hartman
06 Dec, 2007
1 commit
-
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
Cc: Nick Piggin
Cc: David Brownell
Acked-by: Alessandro Zummo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Nov, 2007
1 commit
-
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
Acked-by: Alessandro Zummo
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Oct, 2007
2 commits
-
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
Cc: David Brownell
Cc: Alessandro Zummo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Cc: Alessandro Zummo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
