21 Aug, 2019

1 commit

  • Add a message when __rtc_register_device fails because rtc->ops is NULL.
    This may only happen when developing a new driver so use dev_dbg to avoid
    compiling it in by default.

    Signed-off-by: Alexandre Belloni
    Link: https://lore.kernel.org/r/20190818220041.17833-1-alexandre.belloni@bootlin.com
    Signed-off-by: Alexandre Belloni

    Alexandre Belloni
     

04 Apr, 2019

1 commit


18 Mar, 2019

1 commit


19 Dec, 2018

2 commits


13 Nov, 2018

1 commit


13 Sep, 2018

1 commit


26 Jul, 2018

1 commit


13 Jul, 2018

1 commit

  • getnstimeofday64() is just a wrapper around the ktime accessor, so
    we should use that directly.

    I considered using ktime_get_boottime_ts64() (to avoid leap second
    problems) or ktime_get_real_seconds() (to simplify the calculation,
    but in the end concluded that the existing interface is probably
    the most appropriate in this case.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Alexandre Belloni

    Arnd Bergmann
     

17 Mar, 2018

1 commit

  • From our investigation for all RTC drivers, 1 driver will be expired before
    year 2017, 7 drivers will be expired before year 2038, 23 drivers will be
    expired before year 2069, 72 drivers will be expired before 2100 and 104
    drivers will be expired before 2106. Especially for these early expired
    drivers, we need to expand the RTC range to make the RTC can still work
    after the expired year.

    So we can expand the RTC range by adding one offset to the time when reading
    from hardware, and subtracting it when writing back. For example, if you have
    an RTC that can do 100 years, and currently is configured to be based in
    Jan 1 1970, so it can represents times from 1970 to 2069. Then if you change
    the start year from 1970 to 2000, which means it can represents times from
    2000 to 2099. By adding or subtracting the offset produced by moving the wrap
    point, all times between 1970 and 1999 from RTC hardware could get interpreted
    as times from 2070 to 2099, but the interpretation of dates between 2000 and
    2069 would not change.

    Signed-off-by: Baolin Wang
    Signed-off-by: Alexandre Belloni

    Baolin Wang
     

01 Mar, 2018

2 commits

  • Because nvmem_config is only used and copied at nvmem registration, remove
    it from struct rtc_device.

    All the rtc drivers using nvmem are now calling rtc_nvmem_register
    directly.

    Signed-off-by: Alexandre Belloni

    Alexandre Belloni
     
  • Switch the parent of the nvmem device to the parent of the rtc device so it
    can be registered before the RTC.

    This is a small change in the ABI as the nvmem moves out of the
    /sys/class/rtc/rtcX folder to be under the parent device folder (that is
    where the previous nvram files where registered).

    However, it is still available under its correct location,
    /sys/bus/nvmem/devices which is the one that should be used by userspace
    applications.

    The other benefit is that the nvmem device can stay registered even if the
    rtc registration fails. Or it is possible to not register the rtc if the
    nvmem registration failed.

    Finally, it makes a lot of sense for devices that actually have different
    i2c or spi addresses for the RTC and the EEPROM. That is basically how it
    would end up when using MFD or even completely separate devices.

    Signed-off-by: Alexandre Belloni

    Alexandre Belloni
     

15 Feb, 2018

1 commit


31 Oct, 2017

1 commit

  • ntp is currently hardwired to try and call the rtc set when wall clock
    tv_nsec is 0.5 seconds. This historical behaviour works well with certain
    PC RTCs, but is not universal to all rtc hardware.

    Change how this works by introducing the driver specific concept of
    set_offset_nsec, the delay between current wall clock time and the target
    time to set (with a 0 tv_nsecs).

    For x86-style CMOS set_offset_nsec should be -0.5 s which causes the last
    second to be written 0.5 s after it has started.

    For compat with the old rtc_set_ntp_time, the value is defaulted to
    + 0.5 s, which causes the next second to be written 0.5s before it starts,
    as things were before this patch.

    Testing shows many non-x86 RTCs would like set_offset_nsec ~= 0,
    so ultimately each RTC driver should set the set_offset_nsec according
    to its needs, and non x86 architectures should stop using
    update_persistent_clock64 in order to access this feature.
    Future patches will revise the drivers as needed.

    Since CMOS and RTC now have very different handling they are split
    into two dedicated code paths, sharing the support code, and ifdefs
    are replaced with IS_ENABLED.

    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: Miroslav Lichvar
    Cc: Richard Cochran
    Cc: Prarit Bhargava
    Cc: Stephen Boyd
    Signed-off-by: Jason Gunthorpe
    Signed-off-by: John Stultz

    Jason Gunthorpe
     

07 Jul, 2017

4 commits


03 Jun, 2017

1 commit


21 Mar, 2017

1 commit

  • Mostly straightforward, but we had to remove the rtc_dev_add/del_device
    functions as they split up the cdev_add and the device_add.

    Doing this also revealed that there was likely another subtle bug:
    seeing cdev_add was done after device_register, the cdev probably
    was not ready before device_add when the uevent occurs. This would
    race with userspace, if it tried to use the device directly after
    the uevent. This is fixed just by using the new helper function.

    Another weird thing is this driver would, in some error cases, call
    cdev_add() without calling cdev_init. This patchset corrects this
    by avoiding calling cdev_add if the devt is not set.

    Signed-off-by: Logan Gunthorpe
    Acked-by: Alexandre Belloni
    Signed-off-by: Greg Kroah-Hartman

    Logan Gunthorpe
     

15 Mar, 2016

1 commit

  • The Makefile/Kconfig currently controlling compilation of this code is:

    obj-$(CONFIG_RTC_CLASS) += rtc-core.o
    rtc-core-y := class.o interface.o

    drivers/rtc/Kconfig:menuconfig RTC_CLASS
    drivers/rtc/Kconfig: bool "Real Time Clock"

    ...meaning that it currently is not being built as a module by anyone.

    Lets remove the modular code that is essentially orphaned, so that
    when reading the code there is no doubt it is builtin-only.

    We don't replace module.h with init.h since the file does need
    to know what a struct module is.

    We also delete the MODULE_LICENSE tag etc. since all that information
    is already contained at the top of the file in the comments.

    Signed-off-by: Paul Gortmaker
    Signed-off-by: Alexandre Belloni

    Paul Gortmaker
     

05 Sep, 2015

3 commits

  • Instead of creating wakealarm attribute manually, after the device has been
    registered, let's rely on facilities provided by the attribute groups to
    control which attributes are visible and which are not. This allows to
    create all needed attributes at once, at the same time that we register RTC
    class device.

    Signed-off-by: Dmitry Torokhov
    Reviewed-by: Krzysztof Kozlowski
    Signed-off-by: Alexandre Belloni

    Dmitry Torokhov
     
  • Technically the address of rtc->dev can never be NULL, so get_device()
    can never fail. Also caller of rtc_device_unregister() supposed to be
    the owner of the device and thus have a valid reference. Therefore
    call to get_device() is not needed here.

    Signed-off-by: Dmitry Torokhov
    Reviewed-by: Krzysztof Kozlowski
    Signed-off-by: Alexandre Belloni

    Dmitry Torokhov
     
  • Commit 59cca865f21e ("drivers/rtc/class.c: fix device_register() error
    handling") correctly noted that naked kfree() should not be used after
    failed device_register() call, however, while it added the needed
    put_device() it forgot to remove the original kfree() causing double-free.

    Cc: Vasiliy Kulikov
    Signed-off-by: Dmitry Torokhov
    Reviewed-by: Krzysztof Kozlowski
    Signed-off-by: Alexandre Belloni

    Dmitry Torokhov
     

17 Apr, 2015

1 commit

  • In some error cases RTC name is used before it is initialized:

    rtc-rs5c372 0-0032: clock needs to be set
    rtc-rs5c372 0-0032: rs5c372b found, 24hr, driver version 0.6
    rtc (null): read_time: fail to read
    rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0

    Fix by initializing the name early.

    Signed-off-by: Aaro Koskinen
    Acked-by: Alexandre Belloni
    Cc: Alessandro Zummo
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Aaro Koskinen
     

03 Apr, 2015

2 commits

  • If a system does not provide a persistent_clock(), the time
    will be updated on resume by rtc_resume(). With the addition
    of the non-stop clocksources for suspend timing, those systems
    set the time on resume in timekeeping_resume(), but may not
    provide a valid persistent_clock().

    This results in the rtc_resume() logic thinking no one has set
    the time and it then will over-write the suspend time again,
    which is not necessary and only increases clock error.

    So, fix this for rtc_resume().

    This patch also improves the name of persistent_clock_exist to
    make it more grammatical.

    Signed-off-by: Xunlei Pang
    Signed-off-by: John Stultz
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/1427945681-29972-19-git-send-email-john.stultz@linaro.org
    Signed-off-by: Ingo Molnar

    Xunlei Pang
     
  • rtc_read_time() has already judged valid tm by rtc_valid_tm(),
    so just remove it.

    Signed-off-by: Xunlei Pang
    Signed-off-by: John Stultz
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/1427945681-29972-17-git-send-email-john.stultz@linaro.org
    Signed-off-by: Ingo Molnar

    Xunlei Pang
     

22 Nov, 2014

1 commit


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