Re: [PATCH] rtc/tpo: Handle disabled TPO in opal_get_tpo_time()

[Alexandre Belloni]

On 19/05/2017 at 15:35:09 +0530, Vaibhav Jain wrote:
> 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
> 200557: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 
> Reported-by: Steve Best 
> ---
>  drivers/rtc/rtc-opal.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH] rtc/tpo: Handle disabled TPO in opal_get_tpo_time()

[Vaibhav Jain]

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
200557: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 
Reported-by: Steve Best 
---
 drivers/rtc/rtc-opal.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/rtc/rtc-opal.c b/drivers/rtc/rtc-opal.c
index ea20f62..2d84e2a 100644
--- a/drivers/rtc/rtc-opal.c
+++ b/drivers/rtc/rtc-opal.c
@@ -142,6 +142,16 @@ static int opal_get_tpo_time(struct device *dev, struct 
rtc_wkalrm *alarm)
 
y_m_d = be32_to_cpu(__y_m_d);
h_m_s_ms = ((u64)be32_to_cpu(__h_m) << 32);
+
+   /* check if no alarm is set */
+   if (y_m_d == 0 && h_m_s_ms == 0) {
+   pr_debug("No alarm is set\n");
+   rc = -ENOENT;
+   goto exit;
+   } else {
+   pr_debug("Alarm set to %x %llx\n", y_m_d, h_m_s_ms);
+   }
+
opal_to_tm(y_m_d, h_m_s_ms, >time);
 
 exit:
-- 
2.9.3