linux-stable.git/drivers/rtc, branch linux-2.6.26.y

rtc: fix kernel panic on second use of SIGIO nofitication

2008-10-09T03:23:11+00:00

commit 2e4a75cdcb89ff53bb182dda3a6dcdc14befe007 upstream

When userspace uses SIGIO notification and forgets to disable it before
closing file descriptor, rtc->async_queue contains stale pointer to struct
file.  When user space enables again SIGIO notification in different
process, kernel dereferences this (poisoned) pointer and crashes.

So disable SIGIO notification on close.

Kernel panic:
(second run of qemu (requires echo 1024 > /sys/class/rtc/rtc0/max_user_freq))

general protection fault: 0000 [1] PREEMPT
CPU 0
Modules linked in: af_packet snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq usbhid tuner tea5767 tda8290 tuner_xc2028 xc5000 tda9887 tuner_simple tuner_types mt20xx tea5761 tda9875 uhci_hcd ehci_hcd usbcore bttv snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer ir_common compat_ioctl32 snd_page_alloc videodev v4l1_compat snd_mpu401_uart snd_rawmidi v4l2_common videobuf_dma_sg videobuf_core snd_seq_device snd btcx_risc soundcore tveeprom i2c_viapro
Pid: 5781, comm: qemu-system-x86 Not tainted 2.6.27-rc6 #363
RIP: 0010:[]  [] __lock_acquire+0x3db/0x73f
RSP: 0000:ffffffff80674cb8  EFLAGS: 00010002
RAX: ffff8800224c62f0 RBX: 0000000000000046 RCX: 0000000000000002
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800224c62f0
RBP: ffffffff80674d08 R08: 0000000000000002 R09: 0000000000000001
R10: ffffffff80238941 R11: 0000000000000001 R12: 0000000000000000
R13: 6b6b6b6b6b6b6b6b R14: ffff88003a450080 R15: 0000000000000000
FS:  00007f98b69516f0(0000) GS:ffffffff80623200(0000) knlGS:00000000f7cc86d0
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000a87000 CR3: 0000000022598000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process qemu-system-x86 (pid: 5781, threadinfo ffff880028812000, task ffff88003a450080)
Stack:  ffffffff80674cf8 0000000180238440 0000000200000002 0000000000000000
 ffff8800224c62f0 0000000000000046 0000000000000000 0000000000000002
 0000000000000002 0000000000000000 ffffffff80674d68 ffffffff8024fc7a
Call Trace:
   [] lock_acquire+0x85/0xa9
 [] ? send_sigio+0x2a/0x184
 [] _read_lock+0x3e/0x4a
 [] ? send_sigio+0x2a/0x184
 [] send_sigio+0x2a/0x184
 [] ? __lock_acquire+0x6e1/0x73f
 [] ? kill_fasync+0x2c/0x4e
 [] __kill_fasync+0x54/0x65
 [] kill_fasync+0x3a/0x4e
 [] rtc_update_irq+0x9c/0xa5
 [] cmos_interrupt+0xae/0xc0
 [] handle_IRQ_event+0x25/0x5a
 [] handle_edge_irq+0xdd/0x123
 [] do_IRQ+0xe4/0x144
 [] ret_from_intr+0x0/0xf
   [] ? __alloc_pages_internal+0xe7/0x3ad
 [] ? clear_page_c+0x7/0x10
 [] ? get_page_from_freelist+0x385/0x450
 [] ? __alloc_pages_internal+0xe7/0x3ad
 [] ? anon_vma_prepare+0x2e/0xf6
 [] ? handle_mm_fault+0x227/0x6a5
 [] ? do_page_fault+0x494/0x83f
 [] ? error_exit+0x0/0xa9

Code: cc 41 39 45 28 74 24 e8 5e 1d 0f 00 85 c0 0f 84 6a 03 00 00 83 3d 8f a9 aa 00 00 be 47 03 00 00 0f 84 6a 02 00 00 e9 53 03 00 00 <41> ff 85 38 01 00 00 45 8b be 90 06 00 00 41 83 ff 2f 76 24 e8
RIP  [] __lock_acquire+0x3db/0x73f
 RSP 
---[ end trace 431877d860448760 ]---
Kernel panic - not syncing: Aiee, killing interrupt handler!

Signed-off-by: Marcin Slusarz 
Acked-by: Alessandro Zummo 
Acked-by: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

rtc_time_to_tm: fix signed/unsigned arithmetic

2008-09-08T11:44:20+00:00

commit 73442daf2ea85e2a779396b76b1a39b10188ecb5 upstream

commit 945185a69daa457c4c5e46e47f4afad7dcea734f ("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 
Cc: Maciej W. Rozycki 
Cc: Alessandro Zummo 
Cc: David Brownell 
Cc: Dmitri Vorobiev 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

rtc-at91rm9200: avoid spurious irqs

2008-08-01T19:43:04+00:00

commit 449321b39f6c6ebfa15d6da24f134240bd51db29 upstream

This fixes kernel http://bugzilla.kernel.org/show_bug.cgi?id=11112 (bogus
RTC update IRQs reported) for rtc-at91rm9200 by scrubbing old IRQ status
before enabling IRQs.

It also removes nonfunctional periodic IRQ support from this driver;
only update IRQs are reported, or provided by the hardware.

I suspect some other RTCs probably have versions of #11112; it's easy to
overlook, since most non-RTC drivers don't care about spurious IRQs:
they're not reported to userspace.

Signed-off-by: David Brownell 
Report-by: W Unruh 
Cc: Andrew Victor 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

rtc-pcf8563: add chip id

2008-07-12T21:33:42+00:00

Add the rtc8564 chip entry

Signed-off-by: Jon Smirl 
Signed-off-by: Alessandro Zummo 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc-fm3130: fix chip naming

2008-07-12T21:33:41+00:00

Fix chip naming from fm3031-rtc to fm3031

Signed-off-by: Alessandro Zummo 
Cc: Sergey Lapin 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc-x1205: Fix alarm set

2008-07-04T17:40:05+00:00

I have discovered that the current version of rtc-x1205.c does not work
correctly when asked to set the alarm time by the RTC_WKALM_SET ioctl()
call.  This happens because the alarm registers do not behave like the
current-time registers.  They are non-volatile.  Two things go wrong:

- the X1205 requires a 10 msec delay after any attempt to write to the
  non-volatile registers.  The x1205_set_datetime() routine does the write
  as 8 single-byte writes without any delay.  Only the first write
  succeeds.  The second is NAKed because the chip is busy.

- the X1205 resets the RWEL bit after any write to the non-volatile
  registers.  This would lock out any further writes after the first even
  with a 10msec delay.

I fix this by doing a single 8-byte write and then waiting 10msec for the
chip to be ready.  A side effect of this change is that it will speed up
x1205_rtc_set_time() which uses the same code.

I have also implemented the 'enable' bit in the rtc_wkalm structure, which
the existing driver does not attempt to do.  I have modified both
x1205_rtc_set_alarm() to set the AL0E bit, and x1205_rtc_read_alarm() to
return it.

I have tested this patch on a LinkSys NSLU2 under OpenWRT, but on no other
hardware.  On the NSLU2 the X1205 correctly asserts its IRQ pin when the
alarm time matches the current time.

[akpm@linux-foundation.org: clean up over-parenthesisation]
Signed-off-by: Michael Hamel 
Signed-off-by: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc: rtc_read_alarm() handles wraparound

2008-07-04T17:40:04+00:00

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

[ARM] 5109/1: Mark rtc sa1100 driver as wakeup source before registering it

2008-06-22T13:32:12+00:00

Mark rtc sa1100 driver as wakeup source before registering it.
rtc_device_register evaluates device_can_wakeup(rtc->dev.parent) and
supresses the creation of /sys/class/rtc/rtcX/wakealarm if
device_can_wakeup is not (yet) true.

Signed-off-by: Uli Luckas 
Signed-off-by: Russell King

rtc: Ramtron FM3130 RTC support

2008-06-13T01:05:42+00:00

Ramtron FM3130 is a chip with two separate devices inside, RTC clock and
FRAM.  This driver provides only RTC functionality.

This chip is met in lots of custom boards with AT91SAMXXXX CPU I work
with, is cheap and in no way better or worse than any other RTC on market.
 While it is mostly met on much smaller devices, I think it is great to
have it supported in Linux.

Signed-off-by: Sergey Lapin 
Signed-off-by: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

provide rtc_cmos platform device

2008-06-13T01:05:42+00:00

Recently (around 2.6.25) I've noticed that RTC no longer works for me.  It
turned out this is because I use pnpacpi=off kernel option to work around
the parport_pc bugs.  I always did so, but RTC used to work fine in the
past, and now it have regressed.

The patch fixes the problem by creating the platform device for the RTC
when PNP is disabled.  This may also help running the PNP-enabled kernel
on an older PCs.

Signed-off-by: Stas Sergeev 
Cc: David Brownell 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Bjorn Helgaas 
Cc: Adam Belay 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds