1. 26 Dec, 2015 30 commits
  2. 22 Dec, 2015 4 commits
  3. 21 Dec, 2015 3 commits
  4. 20 Dec, 2015 3 commits
    • Linus Torvalds's avatar
      Merge tag 'rtc-4.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux · 9f7e4327
      Linus Torvalds authored
      Pull RTC fixes from Alexandre Belloni:
       "Late fixes for the RTC subsystem for 4.4:
      
        A fix for a nasty hardware bug in rk808 and an initialization
        reordering in da9063 to fix a possible crash"
      
      * tag 'rtc-4.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux:
        rtc: da9063: fix access ordering error during RTC interrupt at system power on
        rtc: rk808: Compensate for Rockchip calendar deviation on November 31st
      9f7e4327
    • Steve Twiss's avatar
      rtc: da9063: fix access ordering error during RTC interrupt at system power on · 77535ace
      Steve Twiss authored
      This fix alters the ordering of the IRQ and device registrations in the RTC
      driver probe function. This change will apply to the RTC driver that supports
      both DA9063 and DA9062 PMICs.
      
      A problem could occur with the existing RTC driver if:
      
      A system is started from a cold boot using the PMIC RTC IRQ to initiate a
      power on operation. For instance, if an RTC alarm is used to start a
      platform from power off.
      The existing driver IRQ is requested before the device has been properly
      registered.
      i.e.
          ret = devm_request_threaded_irq()
      comes before
          rtc->rtc_dev = devm_rtc_device_register();
      
      In this case, the interrupt can be called before the device has been
      registered and the handler can be called immediately. The IRQ handler
      da9063_alarm_event() contains the function call
      
          rtc_update_irq(rtc->rtc_dev, 1, RTC_IRQF | RTC_AF);
      
      which in turn tries to access the unavailable rtc->rtc_dev.
      
      The fix is to reorder the functions inside the RTC probe. The IRQ is
      requested after the RTC device resource has been registered so that
      get_irq_byname is the last thing to happen.
      Signed-off-by: default avatarSteve Twiss <stwiss.opensource@diasemi.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      77535ace
    • Julius Werner's avatar
      rtc: rk808: Compensate for Rockchip calendar deviation on November 31st · f076ef44
      Julius Werner authored
      In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar
      insufficiently represented reality, and changed the rules about
      calculating leap years to account for this. Similarly, in A.D. 2013
      Rockchip hardware engineers found that the new Gregorian calendar still
      contained flaws, and that the month of November should be counted up to
      31 days instead. Unfortunately it takes a long time for calendar changes
      to gain widespread adoption, and just like more than 300 years went by
      before the last Protestant nation implemented Greg's proposal, we will
      have to wait a while until all religions and operating system kernels
      acknowledge the inherent advantages of the Rockchip system. Until then
      we need to translate dates read from (and written to) Rockchip hardware
      back to the Gregorian format.
      
      This patch works by defining Jan 1st, 2016 as the arbitrary anchor date
      on which Rockchip and Gregorian calendars are in sync. From that we can
      translate arbitrary later dates back and forth by counting the number
      of November/December transitons since the anchor date to determine the
      offset between the calendars. We choose this method (rather than trying
      to regularly "correct" the date stored in hardware) since it's the only
      way to ensure perfect time-keeping even if the system may be shut down
      for an unknown number of years. The drawback is that other software
      reading the same hardware (e.g. mainboard firmware) must use the same
      translation convention (including the same anchor date) to be able to
      read and write correct timestamps from/to the RTC.
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      f076ef44