linux-toradex.git/drivers/rtc/rtc-dev.c, branch v2.6.33.12

headers: remove sched.h from interrupt.h

2009-10-11T18:20:58+00:00

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

rtc: make rtc_update_irq callable with irqs enabled

2009-06-19T23:46:05+00:00

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

rtc: add alarm/update irq interfaces

2009-01-04T21:33:20+00:00

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

saner FASYNC handling on file close

2008-11-01T16:49:46+00:00

As it is, all instances of ->release() for files that have ->fasync()
need to remember to evict file from fasync lists; forgetting that
creates a hole and we actually have a bunch that *does* forget.

So let's keep our lives simple - let __fput() check FASYNC in
file->f_flags and call ->fasync() there if it's been set.  And lose that
crap in ->release() instances - leaving it there is still valid, but we
don't have to bother anymore.

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds

rtc: file close() consistently disables repeating irqs

2008-10-16T18:21:40+00:00

Make the rtc framework consistent about disabling 1/second update IRQs
that may have been activated through the /dev interface, when that /dev
file is closed.  (It may have closed because of coredump, etc.) This was
previously done only for emulated update IRQs ...  now, do it always.

Also comment the current policy: repeating IRQs (periodic, update) that
userspace enabled will be cleanly disabled, but alarms are left alone.
Such repeating IRQs are a constant and pointless system load.

Update some RTC drivers to remove now-needless release() methods.  Most
such methods just enforce that policy.  The others all seem to be buggy,
and mistreat in-kernel clients of periodic or alarm IRQs.

Signed-off-by: David Brownell 
Acked-by: Andrew Sharp 
Cc: Angelo Castello 
Acked-by: Atsushi Nemoto 
Acked-by: Paul Mundt 
Cc: Thomas Hommel 
Acked-by: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc: fix kernel panic on second use of SIGIO nofitication

2008-10-04T01:22:17+00:00

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

rtc: fix double lock on UIE emulation

2008-08-20T22:40:31+00:00

With commit 5ad31a575157147b43fa84ef1e21471661653878 ("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 
Cc: David Brownell 
Cc: Russell King 
Cc: Alessandro Zummo 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

revert "rtc: cdev lock_kernel() pushdown"

2008-08-12T23:07:28+00:00

Revert commit 51a776fa7a7997e726d4a478eda0854c6f9143bd ("rtc: cdev
lock_kernel() pushdown").  The RTC framework does not need BKL
protection.

Signed-off-by: David Brownell 
Cc: Jonathan Corbet 
Cc: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc-dev: stop periodic interrupts on device release

2008-07-30T16:41:47+00:00

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

rtc: don't return -EBUSY when mutex_lock_interruptible() fails

2008-07-30T16:41:45+00:00

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