[LTP] [PATCH v3] rtc02: loosen the compare precision with few seconds

* [LTP] [PATCH v3] rtc02: loosen the compare precision with few seconds
@ 2022-05-11  2:16 Li Wang
  2022-05-11  8:44 ` Cyril Hrubis
  0 siblings, 1 reply; 7+ messages in thread
From: Li Wang @ 2022-05-11  2:16 UTC (permalink / raw)
  To: ltp; +Cc: Eirik Fuller

That possibly has time elapse between the two operations, especially
on VM we can't guarantee the time precisely equal, let's lose a few
seconds to make the test happy:

  tst_test.c:1433: TINFO: Timeout per run is 0h 10m 00s
  rtc02.c:66: TINFO: To set RTC date/time is: 2020-10-09 13:23:30
  rtc02.c:80: TINFO: read RTC date/time is: 2020-10-09 13:23:31
  rtc02.c:83: TFAIL: RTC SET TEST

Signed-off-by: Li Wang <liwang@redhat.com>
Cc: Eirik Fuller <efuller@redhat.com>
Cc: Cyril Hrubis <chrubis@suse.cz>
---

Notes:
    V3:
      I'm also fine to go with only use seconds for hour/min/sec comparsing.
      But that quite no necessary since most of time delta is zero.

 testcases/kernel/device-drivers/rtc/rtc02.c | 54 ++++++++++++++++++---
 1 file changed, 48 insertions(+), 6 deletions(-)

diff --git a/testcases/kernel/device-drivers/rtc/rtc02.c b/testcases/kernel/device-drivers/rtc/rtc02.c
index 0705357bb..dbac11b85 100644
--- a/testcases/kernel/device-drivers/rtc/rtc02.c
+++ b/testcases/kernel/device-drivers/rtc/rtc02.c
@@ -40,12 +40,54 @@ static char *rtctime_to_str(struct rtc_time *tm)
 
 static int rtc_tm_cmp(struct rtc_time *set_tm, struct rtc_time *read_tm)
 {
-	return !((set_tm->tm_sec == read_tm->tm_sec)
-		&& (set_tm->tm_min == read_tm->tm_min)
-		&& (set_tm->tm_hour == read_tm->tm_hour)
-		&& (set_tm->tm_mday == read_tm->tm_mday)
-		&& (set_tm->tm_mon == read_tm->tm_mon)
-		&& (set_tm->tm_year == read_tm->tm_year));
+	long delta, seconds1, seconds2;
+
+	if (set_tm->tm_year != read_tm->tm_year)
+		return 1;
+
+	if (set_tm->tm_mon != read_tm->tm_mon)
+		return 1;
+
+	if (set_tm->tm_mday != read_tm->tm_mday)
+		return 1;
+
+	/*
+	 * Convert hour/min/sec into seconds to handle the normal
+	 * and special situations:
+	 * 1#
+	 *       set_tm:  2022-04-28 13:00:50
+	 *       read_tm: 2022-04-28 13:00:50
+	 * 2#
+	 *       set_tm:  2022-04-28 13:00:50
+	 *       read_tm: 2022-04-28 13:00:51
+	 * 3#
+	 *       set_tm:  2022-04-28 13:00:59
+	 *       read_tm: 2022-04-28 13:01:00
+	 * 4#
+	 *       set_tm:  2022-04-28 13:59:59
+	 *       read_tm: 2022-04-28 14:00:00
+	 *
+	 * Note: as we have avoided testing around the zero
+	 * clock, so it's impossible to hit situation 5#
+	 *       set_tm:  2022-04-28 23:59:59
+	 *       read_tm: 2022-04-29 00:00:00
+	 */
+	if ((set_tm->tm_hour != read_tm->tm_hour)
+		|| (set_tm->tm_min != read_tm->tm_min)
+		|| (set_tm->tm_sec != read_tm->tm_sec)) {
+
+		seconds1 = (set_tm->tm_hour  * 3600) + (set_tm->tm_min  * 60) + set_tm->tm_sec;
+		seconds2 = (read_tm->tm_hour * 3600) + (read_tm->tm_min * 60) + read_tm->tm_sec;
+
+		delta = seconds2 - seconds1;
+
+		if (delta < 0 || delta > 3) {
+			tst_res(TFAIL, "seconds1 is %ld, seconds2 is %ld", seconds1, seconds2);
+			return 1;
+		}
+	}
+
+	return 0;
 }
 
 static void set_rtc_test(void)
-- 
2.31.1


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply related	[flat|nested] 7+ messages in thread