1. 07 Jul, 2017 11 commits
  2. 06 Jul, 2017 9 commits
  3. 05 Jul, 2017 2 commits
  4. 26 Jun, 2017 1 commit
  5. 24 Jun, 2017 9 commits
  6. 03 Jun, 2017 5 commits
  7. 31 May, 2017 3 commits
    • Mauro Carvalho Chehab's avatar
      rtc.txt: standardize document format · a21512c1
      Mauro Carvalho Chehab authored
      Each text file under Documentation follows a different
      format. Some doesn't even have titles!
      
      Change its representation to follow the adopted standard,
      using ReST markups for it to be parseable by Sphinx:
      
      - adjust identation of the titles;
      - mark a table as such;
      - don't capitalize chapter names.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      a21512c1
    • Vaibhav Jain's avatar
      rtc: interface: Validate alarm-time before handling rollover · da96aea0
      Vaibhav Jain authored
      In function __rtc_read_alarm() its possible for an alarm time-stamp to
      be invalid even after replacing missing components with current
      time-stamp. The condition 'alarm->time.tm_year < 70' will trigger this
      case and will cause the call to 'rtc_tm_to_time64(&alarm->time)'
      return a negative value for variable t_alm.
      
      While handling alarm rollover this negative t_alm (assumed to seconds
      offset from '1970-01-01 00:00:00') is converted back to rtc_time via
      rtc_time64_to_tm() which results in this error log with seemingly
      garbage values:
      
      "rtc rtc0: invalid alarm value: -2-1--1041528741
      2005511117:71582844:32"
      
      This error was generated when the rtc driver (rtc-opal in this case)
      returned an alarm time-stamp of '00-00-00 00:00:00' to indicate that
      the alarm is disabled. Though I have submitted a separate fix for the
      rtc-opal driver, this issue may potentially impact other
      existing/future rtc drivers.
      
      To fix this issue the patch validates the alarm time-stamp just after
      filling up the missing datetime components and if rtc_valid_tm() still
      reports it to be invalid then bails out of the function without
      handling the rollover.
      Reported-by: default avatarSteve Best <sbest@redhat.com>
      Signed-off-by: default avatarVaibhav Jain <vaibhav@linux.vnet.ibm.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      da96aea0
    • Vaibhav Jain's avatar
      rtc: opal: Handle disabled TPO in opal_get_tpo_time() · 6dc1cf6f
      Vaibhav Jain authored
      On PowerNV platform when Timed-Power-On(TPO) is disabled, read of
      stored TPO yields value with all date components set to '0' inside
      opal_get_tpo_time(). The function opal_to_tm() then converts it to an
      offset from year 1900 yielding alarm-time == "1900-00-01
      00:00:00". This causes problems with __rtc_read_alarm() that
      expecting an offset from "1970-00-01 00:00:00" and returned alarm-time
      results in a -ve value for time64_t. Which ultimately results in this
      error reported in kernel logs with a seemingly garbage value:
      
      "rtc rtc0: invalid alarm value: -2-1--1041528741
      2005511117:71582844:32"
      
      We fix this by explicitly handling the case of all alarm date-time
      components being '0' inside opal_get_tpo_time() and returning -ENOENT
      in such a case. This signals generic rtc that no alarm is set and it
      bails out from the alarm initialization flow without reporting the
      above error.
      Signed-off-by: default avatarVaibhav Jain <vaibhav@linux.vnet.ibm.com>
      Reported-by: default avatarSteve Best <sbest@redhat.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      6dc1cf6f