12 Oct, 2009

1 commit


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

    Atsushi Nemoto
     

07 Jan, 2009

3 commits


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

    Alessandro Zummo
     

07 Nov, 2008

1 commit


31 Jul, 2008

1 commit


22 Jul, 2008

1 commit


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

    David Brownell
     

25 Jan, 2008

1 commit


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

    Jiri Kosina
     

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

    Jiri Kosina
     

17 Oct, 2007

3 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

    Mark Lord
     
  • 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

    David Brownell
     
  • Add kernel/kernel and kernel/user locking for the periodic irq feature of
    the rtc class.

    PIE ioctls are also supported.

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

    Alessandro Zummo
     

09 May, 2007

3 commits

  • This fixes a common glitch in how RTC drivers handle two "set alarm" modes,
    by getting rid of the surprising/hidden one that was rarely implemented
    correctly (and which could expose nonportable hardware-specific behavior).

    The glitch comes from the /dev/rtcX logic implementing the legacy
    RTC_ALM_SET (limited to 24 hours, needing RTC_AIE_ON) ioctl on top of the
    RTC driver call providing access to the newer RTC_WKALM_SET (without those
    limitations) by initializing the day/month/year fields to be invalid ...
    that second mode.

    Now, since few RTC drivers check those fields, and most hardware misbehaves
    when faced with invalid date fields, many RTC drivers will set bogus alarm
    times on those RTC_ALM_SET code paths. (Several in-tree drivers have that
    issue, and I also noticed it with code reviews on several new RTC drivers.)

    This patch ensures that RTC drivers never see such invalid alarm fields, by
    moving some logic out of rtc-omap into the RTC_ALM_SET code and adding an
    explicit check (which will prevent the issue on other code paths).

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

    David Brownell
     
  • Finish converting the RTC framework so it no longer uses class_device.

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

    David Brownell
     
  • This patch removes class_device from the programming interface that the RTC
    framework exposes to the rest of the kernel. Now an rtc_device is passed,
    which is more type-safe and streamlines all the relevant code.

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

    David Brownell
     

02 Mar, 2007

1 commit

  • Fix an oops on the rtc_device_unregister() path by waiting until the last
    moment before nulling the rtc->ops vector. Fix some potential oopses by
    having the rtc_class_open()/rtc_class_close() interface increase the RTC's
    reference count while an RTC handle is available outside the RTC framework.

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

    David Brownell
     

26 Nov, 2006

2 commits

  • I got a lockdep warning when running "rtctest" so I though it'd be good
    to see what was up.

    - The warning was for rtc->irq_task_lock, gotten from rtc_update_irq()
    by irq handlerss ... but in a handful of other cases, grabbed without
    blocking IRQs.

    - Some callers to rtc_update_irq() were not ensuring IRQs were blocked,
    yet the routine expects that; make sure all callers block IRQs.

    It would appear that RTC API tests haven't been part of anyone's kernel
    regression test suite recently, at least not with lockdep running.

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

    David Brownell
     
  • The RTC framework has an irq_set_freq() method that should be used to manage
    the periodic IRQ frequency, but the current ioctl logic doesn't know how to do
    that. This patch teaches it how.

    This means that drivers implementing irq_set_freq() will automatically support
    RTC_IRQP_{READ,SET} ioctls; that logic doesn't need duplication within the
    driver.

    [akpm@osdl.org: export rtc_irq_set_freq]
    Signed-off-by: David Brownell
    Acked-by: Alessandro Zummo
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     

26 Jun, 2006

1 commit


28 Mar, 2006

1 commit

  • Add the basic RTC subsystem infrastructure to the kernel.

    rtc/class.c - registration facilities for RTC drivers
    rtc/interface.c - kernel/rtc interface functions
    rtc/hctosys.c - snippet of code that copies hw clock to sw clock
    at bootup, if configured to do so.

    Signed-off-by: Alessandro Zummo
    Acked-by: Greg Kroah-Hartman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alessandro Zummo