Update rtc-cmos shutdown handling to leave RTC alarms active, resolving
http://bugzilla.kernel.org/show_bug.cgi?id=11411 on several boards. There
are still some systems where the ACPI event handling doesn't cooperate.
(Possibly related to bugid 11312, reporting the spontaneous disabling of
RTC events.)
Bug 11411 reported that changes to work around some ACPI event issues
broke wake-from-S5 handling, as used for DVR applications. (They like to
power off, then wake later to record programs.)
[yakui.zhao@intel.com: add shutdown for PNP devices]
[dbrownell@users.sourceforge.net: update comments]
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Stefan Bauer <stefan.bauer@cs.tu-chemnitz.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
commit 945185a69d ("rtc: rtc_time_to_tm: use
unsigned arithmetic") changed the some types in rtc_time_to_tm() to
unsigned:
void rtc_time_to_tm(unsigned long time, struct rtc_time *tm)
{
- register int days, month, year;
+ unsigned int days, month, year;
This doesn't work for all cases, because days is checked for < 0 later
on:
if (days < 0) {
year -= 1;
days += 365 + LEAP_YEAR(year);
}
I think the correct fix would be to keep days signed and do an appropriate
cast later on.
Signed-off-by: Jan Altenberg <jan.altenberg@linutronix.de>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: David Brownell <david-b@pacbell.net>
Cc: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch lets the files using linux/version.h match the files that
#include it.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On a PowerPC board with ds1374 RTC I'm getting this error while RTC tries
to probe:
rtc-ds1374 0-0068: unable to request IRQ
This happens because I2C probing code (drivers/of/of_i2c.c) is specifying
IRQ0 for 'no irq' case, which is correct.
The driver handles this incorrectly, though. This patch fixes it.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
With commit 5ad31a5751 ("rtc: remove BKL
for ioctl()"), RTC_UIE_ON ioctl cause double lock on rtc->ops_lock.
The ops_lock must not be held while set_uie() calls rtc_read_time()
which takes the lock. Also clear_uie() does not need ops_lock. This
patch fixes return value of RTC_UIE_OFF ioctl too.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: David Brownell <david-b@pacbell.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove includes of asm/hardware.h in addition to asm/arch/hardware.h.
Then, since asm/hardware.h only exists to include asm/arch/hardware.h,
update everything to directly include asm/arch/hardware.h and remove
asm/hardware.h.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Solves http://bugzilla.kernel.org/show_bug.cgi?id=11127
The old rtc.c driver did it and some drivers (like rtc-sh) do it in their
release function, though they should not -- because they should provide
the irq_set_state op and the rtc framework itself should care about it.
This patch makes it do so.
I am aware that some drivers, like rtc-sh, handle userspace PIE sets in
their ioctl op (instead of having the framework call the op), exporting
the irq_set_state op at the same time. The logic in rtc_irq_set_state
should make sure it doesn't matter and the driver should not need to care
stopping periodic interrupts in its release routine any more.
The correct way, in my opinion, should be this:
1) The driver provides the irq_set_state op and does not care closing the
interrupts in its release op.
2) If the driver does not provide the op and handles PIE in the ioctl op, it's
reponsible for closing them in its release op.
3) Something similar for other IRQs, like UIE -- if there's no in-kernel API
like irq_set_state, handle it in ioctl and release ops. The framework will
be responsible either for everything or for nothing. (This will probably
change later.)
Signed-off-by: Tomas Janousek <tomi@nomi.cz>
Acked-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>
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>
