diff options
| author | Vaibhav Jain <vaibhav@linux.vnet.ibm.com> | 2017-05-19 12:05:09 +0200 |
|---|---|---|
| committer | Alexandre Belloni <alexandre.belloni@free-electrons.com> | 2017-05-31 12:57:37 +0200 |
| commit | 6dc1cf6f932bb0ea4d8f5e913a0a401ecacd2f03 (patch) | |
| tree | a614e80f56498eef02813108598fcd60a4c4a133 /Documentation/siphash.txt | |
| parent | rtc: m41t80: add clock provider support (diff) | |
| download | linux-6dc1cf6f932bb0ea4d8f5e913a0a401ecacd2f03.tar.xz linux-6dc1cf6f932bb0ea4d8f5e913a0a401ecacd2f03.zip | |
rtc: opal: Handle disabled TPO in opal_get_tpo_time()
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: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Reported-by: Steve Best <sbest@redhat.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Diffstat (limited to 'Documentation/siphash.txt')
0 files changed, 0 insertions, 0 deletions