linux.git/drivers/rtc/rtc-dev.c, branch v2.6.27-rc4

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

rtc: remove BKL for ioctl()

2008-07-24T17:47:33+00:00

Remove implicit use of BKL in ioctl() from the RTC framework.

Instead, the rtc->ops_lock is used.  That's the same lock that already
protects the RTC operations when they're issued through the exported
rtc_*() calls in drivers/rtc/interface.c ...  making this a bugfix, not
just a cleanup, since both ioctl calls and set_alarm() need to update IRQ
enable flags and that implies a common lock (which RTC drivers as a rule
do not provide on their own).

A new comment at the declaration of "struct rtc_class_ops" summarizes
current locking rules.  It's not clear to me that the exceptions listed
there should exist ...  if not, those are pre-existing problems which can
be fixed in a patch that doesn't relate to BKL removal.

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

rtc: cdev lock_kernel() pushdown

2008-06-20T20:03:43+00:00

Signed-off-by: Jonathan Corbet

rtc-cmos alarm acts as oneshot

2008-02-06T18:41:13+00:00

Start making the rtc-cmos alarm act more like a oneshot alarm by disabling
that alarm after its IRQ fires.  (ACPI hooks are also needed.)

The Linux RTC framework has previously been a bit vague in this area, but
any other behavior is problematic and not very portable.  RTCs with full
YYYY-MM-DD HH:MM[:SS] alarms won't have a problem here.  Only ones with
partial match criteria, with the most visible example being the PC RTC, get
confused.  (Because the criteria will match repeatedly.)

Update comments relating to that oneshot behavior and timezone handling.
(Timezones are another issue that's mostly visible with rtc-cmos.  That's
because PCs often dual-boot MS-Windows, which likes its RTC to match local
wall-clock time instead of UTC.)

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

RTC: assure proper memory ordering with respect to RTC_DEV_BUSY flag

2007-12-05T17:21:18+00:00

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

RTC: convert mutex to bitfield

2007-11-29T17:24:54+00:00

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

rtc: allow validated RTC_PIE_ON for non-root

2007-10-16T16:43:13+00:00

drivers/char/rtc.c allowed RTC_PIE_ON ioctls for non-root users, as long as
the current interval (set via RTC_IRQP_SET) is <= max_user_freq.  Allow
RTC_PIE_ON under the same conditions when /dev/rtc* is handled by the rtc
subsystem.

Signed-off-by: Bryan Kadzban 
Acked-by: Alessandro Zummo 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds