09 Aug, 2014

1 commit

  • In rtc_suspend() and rtc_resume(), the error after rtc_read_time() is not
    checked. If rtc device fail to read time, we cannot guarantee the
    following process.

    Add the verification code for returned rtc_read_time() error.

    Signed-off-by: Hyogi Gim
    Cc: Alessandro Zummo
    Cc: "Rafael J. Wysocki"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hyogi Gim
     

24 Jan, 2014

1 commit

  • Assign RTC device IDs based on device tree /aliases entries if present,
    falling back to the existing numbering scheme if there is no /aliases
    entry (which includes when the system isn't booted using DT), or there is
    a numbering conflict.

    This is useful in systems with multiple RTC devices, to ensure that the
    best RTC device is selected as /dev/rtc0, which provides the overall
    system time.

    For example, Tegra has an on-SoC RTC that is not battery backed, typically
    coupled with an off-SoC RTC that is battery backed. Only the latter is
    useful for populating the system time, yet the former is useful e.g. for
    wakeup timing, since the time is not lost when the system is sleeps.

    Signed-off-by: Stephen Warren
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stephen Warren
     

04 Jul, 2013

1 commit

  • Convert drivers/rtc/class to use dev_pm_ops for power management and
    remove Legacy PM ops hooks. With this change, rtc class registers
    suspend/resume callbacks via class->pm (dev_pm_ops) instead of Legacy
    class->suspend/resume. When __device_suspend() runs call-backs, it will
    find class->pm ops for the rtc class.

    Signed-off-by: Shuah Khan
    Signed-off-by: Jingoo Han
    Cc: Shuah Khan
    Cc: Alessandro Zummo
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Shuah Khan
     

30 Apr, 2013

2 commits


22 Feb, 2013

1 commit


04 Feb, 2013

1 commit


16 Jan, 2013

1 commit


21 Dec, 2012

1 commit

  • Revert commit 2830a6d20139df2198d63235df7957712adb28e5.

    We already perform the ida_simple_remove() in rtc_device_release(),
    which is an appropriate place. Commit 2830a6d20 ("rtc: recycle id when
    unloading a rtc driver") caused the kernel to emit

    ida_remove called for id=0 which is not allocated.

    warnings when rtc_device_release() tries to release an alread-released
    ID.

    Let's restore things to their previous state and then work out why
    Vincent's kernel wasn't calling rtc_device_release() - presumably a bug
    in a specific sub-driver.

    Reported-by: Lothar Waßmann
    Acked-by: Alexander Holler
    Cc: Vincent Palatin
    Cc: [3.7.x]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

06 Oct, 2012

2 commits

  • Without this patch /sys/class/rtc/$CONFIG_RTC_HCTOSYS_DEVICE/hctosys
    contains a 1 (meaning "This rtc was used to initialize the system
    clock") even if setting the time by do_settimeofday() at bootup failed.
    The RTC can also be used to set the clock on resume, if it did 1,
    otherwise 0. Previously there was no indication if the RTC was used
    to set the clock in resume.

    This uses only CONFIG_RTC_HCTOSYS_DEVICE for conditional compilation
    instead of it and CONFIG_RTC_HCTOSYS to be more consistent.
    rtc_hctosys_ret was moved to class.c so class.c no longer depends on
    hctosys.c.

    [sfr@canb.auug.org.au: fix build]
    Signed-off-by: David Fries
    Cc: Matthew Garrett
    Cc: Alessandro Zummo
    Cc: Uwe Kleine-König
    Signed-off-by: Stephen Rothwell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Fries
     
  • When calling rtc_device_unregister, we are not freeing the id used by the
    driver. So when doing a unload/load cycle for a RTC driver (e.g. rmmod
    rtc_cmos && modprobe rtc_cmos), its id is incremented by one. As a
    consequence, we no longer have neither an rtc0 driver nor a
    /proc/driver/rtc (as it only exists for the first driver).

    Signed-off-by: Vincent Palatin
    Cc: Alessandro Zummo
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vincent Palatin
     

06 Dec, 2011

1 commit


23 Nov, 2011

1 commit

  • The current code checks if abs(delta_delta.tv_sec) is greater or
    equal to two before it discards the old delta value, but this can
    trigger at close to -1 seconds since -1.000000001 seconds is stored
    as tv_sec -2 and tv_nsec 999999999 in a normalized timespec.

    rtc_resume had an early return check if the rtc value had not changed
    since rtc_suspend. This effectivly stops time for the duration of the
    short sleep. Check if sleep_time is positive after all the adjustments
    have been applied instead since this allows the old_system adjustment
    in rtc_suspend to have an effect even for short sleep cycles.

    CC: stable@kernel.org
    Signed-off-by: Arve Hjønnevåg
    Signed-off-by: John Stultz

    Arve Hjønnevåg
     

03 Nov, 2011

1 commit


22 Jun, 2011

1 commit

  • Because the RTC interface is only a second granular interface,
    each time we read from the RTC for suspend/resume, we introduce a
    half second (on average) of error.

    In order to avoid this error accumulating as the system is suspended
    over and over, this patch measures the time delta between the RTC
    and the system CLOCK_REALTIME.

    If the delta is less then 2 seconds from the last suspend, we compensate
    by using the previous time delta (keeping it close). If it is larger
    then 2 seconds, we assume the clock was set or has been changed, so we
    do no correction and update the delta.

    Note: If NTP is running, ths could seem to "fight" with the NTP corrected
    time, where as if the system time was off by 1 second, and NTP slewed the
    value in, a suspend/resume cycle could undo this correction, by trying to
    restore the previous offset from the RTC. However, without this patch,
    since each read could cause almost a full second worth of error, its
    possible to get almost 2 seconds of error just from the suspend/resume
    cycle alone, so this about equal to any offset added by the compensation.

    Further on systems that suspend/resume frequently, this should keep time
    closer then NTP could compensate for if the errors were allowed to
    accumulate.

    Credits to Arve Hjønnevåg for suggesting this solution.

    This patch also improves some of the variable names and adds more clear
    comments.

    CC: Arve Hjønnevåg
    CC: Thomas Gleixner
    Signed-off-by: John Stultz

    John Stultz
     

27 Apr, 2011

1 commit

  • Some platforms cannot implement read_persistent_clock, as
    their RTC devices are only accessible when interrupts are enabled.
    This keeps them from being used by the timekeeping code on resume
    to measure the time in suspend.

    The RTC layer tries to work around this, by calling do_settimeofday
    on resume after irqs are reenabled to set the time properly. However,
    this only corrects CLOCK_REALTIME, and does not properly adjust
    the sleep time value. This causes btime in /proc/stat to be incorrect
    as well as making the new CLOCK_BOTTTIME inaccurate.

    This patch resolves the issue by introducing a new timekeeping hook
    to allow the RTC layer to inject the sleep time on resume.

    The code also checks to make sure that read_persistent_clock is
    nonfunctional before setting the sleep time, so that should the RTC's
    HCTOSYS option be configured in on a system that does support
    read_persistent_clock we will not increase the total_sleep_time twice.

    CC: Arve Hjønnevåg
    CC: Thomas Gleixner
    Acked-by: Arnd Bergmann
    Signed-off-by: John Stultz

    John Stultz
     

30 Mar, 2011

1 commit

  • When we register an rtc device at boot, we read the alarm value
    in hardware and set the rtc device's aie_timer to that value.

    The initial method to do this was to simply call rtc_set_alarm()
    with the value read from hardware. However, this may cause problems
    as rtc_set_alarm may enable interupts, and the RTC alarm might fire,
    which can cause invalid pointer dereferencing since the RTC registration
    is not complete.

    This patch solves the issue by initializing the rtc_device.aie_timer
    y hand via rtc_initialize_alarm(). This avoids any calls to the RTC
    hardware which might enable interrupts too early.

    CC: Thomas Gleixner
    CC: Alessandro Zummo
    Reported-by: Konrad Rzeszutek Wilk
    Tested-by: Konrad Rzeszutek Wilk
    Signed-off-by: John Stultz

    John Stultz
     

10 Mar, 2011

1 commit

  • Mark Brown pointed out a corner case: that RTC alarms should
    be allowed to be persistent across reboots if the hardware
    supported it.

    The rework of the generic layer to virtualize the RTC alarm
    virtualized much of the alarm handling, and removed the
    code used to read the alarm time from the hardware.

    Mark noted if we want the alarm to be persistent across
    reboots, we need to re-read the alarm value into the
    virtualized generic layer at boot up, so that the generic
    layer properly exposes that value.

    This patch restores much of the earlier removed
    rtc_read_alarm code and wires it in so that we
    set the kernel's alarm value to what we find in the
    hardware at boot time.

    NOTE: Not all hardware supports persistent RTC alarm state across
    system reset. rtc-cmos for example will keep the alarm time, but
    disables the AIE mode irq. Applications should not expect the RTC
    alarm to be valid after a system reset. We will preserve what
    we can, to represent the hardware state at boot, but its not
    guarenteed.

    Further, in the future, with multiplexed RTC alarms, the
    soonest alarm to fire may not be the one set via the /dev/rt
    ioctls. So an application may set the alarm with RTC_ALM_SET,
    but after a reset find that RTC_ALM_READ returns an earlier
    time. Again, we preserve what we can, but applications should
    not expect the RTC alarm state to persist across a system reset.

    Big thanks to Mark for pointing out the issue!
    Thanks also to Marcelo for helping think through the solution.

    CC: Mark Brown
    CC: Marcelo Roberto Jimenez
    CC: Thomas Gleixner
    CC: Alessandro Zummo
    CC: rtc-linux@googlegroups.com
    Reported-by: Mark Brown
    Signed-off-by: John Stultz

    John Stultz
     

04 Feb, 2011

1 commit

  • This patch prevents a user space program from calling the RTC_IRQP_SET
    ioctl with a negative value of frequency. Also, if this call is make
    with a zero value of frequency, there would be a division by zero in the
    kernel code.

    [jstultz: Also initialize irq_freq to 1 to catch other divbyzero issues]

    CC: Alessandro Zummo
    CC: Thomas Gleixner
    Signed-off-by: Marcelo Roberto Jimenez
    Signed-off-by: John Stultz

    Marcelo Roberto Jimenez
     

12 Jan, 2011

1 commit


14 Dec, 2010

1 commit

  • rtctimer_* is already occupied by sound/core/rtctimer.c. Instead of
    fiddling with that, rename the new functions to rtc_timer_* which
    reads nicer anyway.

    Signed-off-by: Thomas Gleixner
    Cc: John Stultz

    Thomas Gleixner
     

11 Dec, 2010

1 commit

  • This patch reworks a large portion of the generic RTC code
    to in-effect virtualize the rtc interrupt code.

    The current RTC interface is very much a raw hardware interface.
    Via the proc, /dev/, or sysfs interfaces, applciations can set
    the hardware to trigger interrupts in one of three modes:

    AIE: Alarm interrupt
    UIE: Update interrupt (ie: once per second)
    PIE: Periodic interrupt (sub-second irqs)

    The problem with this interface is that it limits the RTC hardware
    so it can only be used by one application at a time.

    The purpose of this patch is to extend the RTC code so that we can
    multiplex multiple applications event needs onto a single RTC device.
    This is done by utilizing the timerqueue infrastructure to manage
    a list of events, which cause the RTC hardware to be programmed
    to fire an interrupt for the next event in the list.

    In order to preserve the functionality of the exsting proc,/dev/ and
    sysfs interfaces, we emulate the different interrupt modes as follows:

    AIE: We create a rtc_timer dedicated to AIE mode interrupts. There is
    only one per device, so we don't change existing interface semantics.

    UIE: Again, a dedicated rtc_timer, set for periodic mode, is used
    to emulate UIE interrupts. Again, only one per device.

    PIE: Since PIE mode interrupts fire faster then the RTC's clock read
    granularity, we emulate PIE mode interrupts using a hrtimer. Again,
    one per device.

    With this patch, the rtctest.c application in Documentation/rtc.txt
    passes fine on x86 hardware. However, there may very well still be
    bugs, so greatly I'd appreciate any feedback or testing!

    Signed-off-by: John Stultz
    LKML Reference:
    Acked-by: Alessandro Zummo
    Reviewed-by: Thomas Gleixner
    CC: Alessandro Zummo
    CC: Thomas Gleixner
    CC: Richard Cochran

    John Stultz
     

28 Oct, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

07 Mar, 2010

1 commit

  • The idr should be destroyed when the module is unloaded. Found with
    kmemleak.

    Signed-off-by: Aaro Koskinen
    Cc: Alessandro Zummo
    Cc: stable
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Aaro Koskinen
     

07 Jan, 2009

1 commit