[LTP] [PATCH v3] rtc02: loosen the compare precision with few seconds
Li Wang
liwang@redhat.com
Wed May 11 04:16:36 CEST 2022
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
More information about the ltp
mailing list