[PATCH 0/4] time: time64_to_tm() cleanups

[PATCH 0/4] time: time64_to_tm() cleanups

[Thomas Weißschuh (Schneider Electric)]

Speed up time64_to_tm() and its tests a bit.
Also simplify drop the custom implementation of rtc_time64_to_tm()
and the test for it.

The series could be split. Then patches 1 and 2 go through timekeeping
while 3 and 4 go through RTC.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Thomas Weißschuh (Schneider Electric) (4):
      time: Avoid 64-bit by 64-bit division in time64_to_tm()
      time: test: Avoid unnecessary divisions in time64_to_tm() test
      rtc: lib: Implement time64_to_tm() in terms of time64_to_tm()
      rtc: test: Remove test_rtc_lib.c

 drivers/rtc/Kconfig        |   9 ----
 drivers/rtc/Makefile       |   2 -
 drivers/rtc/lib.c          | 117 ++++++---------------------------------------
 drivers/rtc/test_rtc_lib.c | 106 ----------------------------------------
 kernel/time/time_test.c    |   6 +--
 kernel/time/timeconv.c     |   4 +-
 6 files changed, 20 insertions(+), 224 deletions(-)
---
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
change-id: 20260831-time-time64-to-tm-960ac8bcd71f

Best regards,
--  
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

[PATCH 1/4] time: Avoid 64-bit by 64-bit division in time64_to_tm()

[Thomas Weißschuh (Schneider Electric)]

As the divisor is static and known to fit into 32 bits, a 64/32 division
is enough. The 64/64 is unnecessary and very expensive on architectures
without native 64/64 division instructions.

This brings the time64_to_tm_test_date_range() runtime from 45 seconds
down to 30 seconds in an emulated 32-bit ARM machine.

Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de>
---
 kernel/time/timeconv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/time/timeconv.c b/kernel/time/timeconv.c
index 59b922c826e7..779b91898276 100644
--- a/kernel/time/timeconv.c
+++ b/kernel/time/timeconv.c
@@ -105,8 +105,8 @@ void time64_to_tm(time64_t totalsecs, int offset, struct tm *result)
 	udays	= ((u64) days) + 2305843009213814918ULL;
 
 	u64tmp		= 4 * udays + 3;
-	century		= div64_u64_rem(u64tmp, 146097, &u64tmp);
-	day_of_century	= (u32) (u64tmp / 4);
+	century		= div_u64_rem(u64tmp, 146097, &u32tmp);
+	day_of_century	= u32tmp / 4;
 
 	u32tmp		= 4 * day_of_century + 3;
 	u64tmp		= 2939745ULL * u32tmp;

-- 
2.55.0

Re: [PATCH 1/4] time: Avoid 64-bit by 64-bit division in time64_to_tm()

[sashiko-bot]

> As the divisor is static and known to fit into 32 bits, a 64/32 division
> is enough. The 64/64 is unnecessary and very expensive on architectures
> without native 64/64 division instructions.
> 
> This brings the time64_to_tm_test_date_range() runtime from 45 seconds
> down to 30 seconds in an emulated 32-bit ARM machine.
> 
> Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-time-time64-to-tm-v1-0-660be972adfc@linutronix.de?part=1

[PATCH 2/4] time: test: Avoid unnecessary divisions in time64_to_tm() test

[Thomas Weißschuh (Schneider Electric)]

The time64_to_tm_test_date_range() test case is slow.
One big part of this slowness is the division done in the test loop to
calculate the current day from the current seconds. As each test loop
advances the time by one day, that division can be avoided.

Remove the division and instead increment the 'days' variable directly.

This brings the test's runtime from 30 seconds down to 15 seconds in an
emulated 32-bit ARM machine.

Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de>
---
 kernel/time/time_test.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/time/time_test.c b/kernel/time/time_test.c
index 1b99180da288..70b20c5c7336 100644
--- a/kernel/time/time_test.c
+++ b/kernel/time/time_test.c
@@ -69,12 +69,12 @@ static void time64_to_tm_test_date_range(struct kunit *test)
 	time64_t secs;
 	s64 days;
 
-	for (secs = -total_secs; secs <= total_secs; secs += 86400) {
+	for (secs = -total_secs, days = div_s64(secs, 86400);
+	     secs <= total_secs;
+	     secs += 86400, days++) {
 
 		time64_to_tm(secs, 0, &result);
 
-		days = div_s64(secs, 86400);
-
 		#define FAIL_MSG "%05ld/%02d/%02d (%2d) : %lld", \
 			year, month, mdday, yday, days
 

-- 
2.55.0

Re: [PATCH 2/4] time: test: Avoid unnecessary divisions in time64_to_tm() test

[sashiko-bot]

> The time64_to_tm_test_date_range() test case is slow.
> One big part of this slowness is the division done in the test loop to
> calculate the current day from the current seconds. As each test loop
> advances the time by one day, that division can be avoided.
> 
> Remove the division and instead increment the 'days' variable directly.
> 
> This brings the test's runtime from 30 seconds down to 15 seconds in an
> emulated 32-bit ARM machine.
> 
> Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-time-time64-to-tm-v1-0-660be972adfc@linutronix.de?part=2

[PATCH 3/4] rtc: lib: Implement time64_to_tm() in terms of time64_to_tm()

[Thomas Weißschuh (Schneider Electric)]

The core timekeeping code already provides a function to convert seconds
since the epoch to a 'struct tm'. This can be reused for a the
'struct rtc_time' conversion.

time64_to_tm() can handle a larger range of dates. It is also
20% slower, but this function is not a hot-path anyways.
On the other hand this saves ~600 bytes of .text.

Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de>
---
 drivers/rtc/lib.c | 117 +++++++-----------------------------------------------
 1 file changed, 15 insertions(+), 102 deletions(-)

diff --git a/drivers/rtc/lib.c b/drivers/rtc/lib.c
index f7051592a6e3..48a26b579b4c 100644
--- a/drivers/rtc/lib.c
+++ b/drivers/rtc/lib.c
@@ -46,110 +46,23 @@ EXPORT_SYMBOL(rtc_year_days);
  * rtc_time64_to_tm - converts time64_t to rtc_time.
  *
  * @time:	The number of seconds since 01-01-1970 00:00:00.
- *		Works for values since at least 1900
- * @tm:		Pointer to the struct rtc_time.
+ * @rtc_tm:	Pointer to the struct rtc_time.
  */
-void rtc_time64_to_tm(time64_t time, struct rtc_time *tm)
+noinline void rtc_time64_to_tm(time64_t time, struct rtc_time *rtc_tm)
 {
-	int secs;
-
-	u64 u64tmp;
-	u32 u32tmp, udays, century, day_of_century, year_of_century, year,
-		day_of_year, month, day;
-	bool is_Jan_or_Feb, is_leap_year;
-
-	/*
-	 * The time represented by `time` is given in seconds since 1970-01-01
-	 * (UTC). As the division done below might misbehave for negative
-	 * values, we convert it to seconds since 0000-03-01 and then assume it
-	 * will be non-negative.
-	 * Below we do 4 * udays + 3 which should fit into a 32 bit unsigned
-	 * variable. So the latest date this algorithm works for is 1073741823
-	 * days after 0000-03-01 which is in the year 2939805.
-	 */
-	time += (u64)719468 * 86400;
-
-	udays = div_s64_rem(time, 86400, &secs);
-
-	/*
-	 * day of the week, 0000-03-01 was a Wednesday (in the proleptic
-	 * Gregorian calendar)
-	 */
-	tm->tm_wday = (udays + 3) % 7;
-
-	/*
-	 * The following algorithm is, basically, Figure 12 of Neri
-	 * and Schneider [1]. In a few words: it works on the computational
-	 * (fictitious) calendar where the year starts in March, month = 2
-	 * (*), and finishes in February, month = 13. This calendar is
-	 * mathematically convenient because the day of the year does not
-	 * depend on whether the year is leap or not. For instance:
-	 *
-	 * March 1st		0-th day of the year;
-	 * ...
-	 * April 1st		31-st day of the year;
-	 * ...
-	 * January 1st		306-th day of the year; (Important!)
-	 * ...
-	 * February 28th	364-th day of the year;
-	 * February 29th	365-th day of the year (if it exists).
-	 *
-	 * After having worked out the date in the computational calendar
-	 * (using just arithmetics) it's easy to convert it to the
-	 * corresponding date in the Gregorian calendar.
-	 *
-	 * [1] Neri C, Schneider L. Euclidean affine functions and their
-	 *     application to calendar algorithms. Softw Pract Exper.
-	 *     2023;53(4):937-970. doi: 10.1002/spe.3172
-	 *     https://doi.org/10.1002/spe.3172
-	 *
-	 * (*) The numbering of months follows rtc_time more closely and
-	 * thus, is slightly different from [1].
-	 */
-
-	u32tmp		= 4 * udays + 3;
-	century		= u32tmp / 146097;
-	day_of_century	= u32tmp % 146097 / 4;
-
-	u32tmp		= 4 * day_of_century + 3;
-	u64tmp		= 2939745ULL * u32tmp;
-	year_of_century	= upper_32_bits(u64tmp);
-	day_of_year	= lower_32_bits(u64tmp) / 2939745 / 4;
-
-	year		= 100 * century + year_of_century;
-	is_leap_year	= year_of_century != 0 ?
-		year_of_century % 4 == 0 : century % 4 == 0;
-
-	u32tmp		= 2141 * day_of_year + 132377;
-	month		= u32tmp >> 16;
-	day		= ((u16) u32tmp) / 2141;
-
-	/*
-	 * Recall that January 01 is the 306-th day of the year in the
-	 * computational (not Gregorian) calendar.
-	 */
-	is_Jan_or_Feb	= day_of_year >= 306;
-
-	/* Converts to the Gregorian calendar. */
-	year		= year + is_Jan_or_Feb;
-	month		= is_Jan_or_Feb ? month - 12 : month;
-	day		= day + 1;
-
-	day_of_year	= is_Jan_or_Feb ?
-		day_of_year - 306 : day_of_year + 31 + 28 + is_leap_year;
-
-	/* Converts to rtc_time's format. */
-	tm->tm_year	= (int) (year - 1900);
-	tm->tm_mon	= (int) month;
-	tm->tm_mday	= (int) day;
-	tm->tm_yday	= (int) day_of_year + 1;
-
-	tm->tm_hour = secs / 3600;
-	secs -= tm->tm_hour * 3600;
-	tm->tm_min = secs / 60;
-	tm->tm_sec = secs - tm->tm_min * 60;
-
-	tm->tm_isdst = 0;
+	struct tm tm;
+
+	time64_to_tm(time, 0, &tm);
+
+	rtc_tm->tm_wday		= tm.tm_wday;
+	rtc_tm->tm_year		= tm.tm_year;
+	rtc_tm->tm_mon		= tm.tm_mon;
+	rtc_tm->tm_mday		= tm.tm_mday;
+	rtc_tm->tm_yday		= tm.tm_yday + 1;
+	rtc_tm->tm_hour		= tm.tm_hour;
+	rtc_tm->tm_min		= tm.tm_min;
+	rtc_tm->tm_sec		= tm.tm_sec;
+	rtc_tm->tm_isdst	= 0;
 }
 EXPORT_SYMBOL(rtc_time64_to_tm);
 

-- 
2.55.0

Re: [PATCH 3/4] rtc: lib: Implement time64_to_tm() in terms of time64_to_tm()

[sashiko-bot]

> The core timekeeping code already provides a function to convert seconds
> since the epoch to a 'struct tm'. This can be reused for a the
> 'struct rtc_time' conversion.
> 
> time64_to_tm() can handle a larger range of dates. It is also
> 20% slower, but this function is not a hot-path anyways.
> On the other hand this saves ~600 bytes of .text.
> 
> Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-time-time64-to-tm-v1-0-660be972adfc@linutronix.de?part=3

[PATCH 4/4] rtc: test: Remove test_rtc_lib.c

[Thomas Weißschuh (Schneider Electric)]

Now that rtc_time64_to_tm() is only a thin wrapper around time64_to_tm()
the dedicated test is not necessary anymore. time64_to_tm() is already
tested with a similar test in kernel/time/time_test.c

Remove it.

Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de>
---
 drivers/rtc/Kconfig        |   9 ----
 drivers/rtc/Makefile       |   2 -
 drivers/rtc/test_rtc_lib.c | 106 ---------------------------------------------
 3 files changed, 117 deletions(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 05b9233b9418..b507ed2f10e7 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -75,15 +75,6 @@ config RTC_DEBUG
 	  Say yes here to enable debugging support in the RTC framework
 	  and individual RTC drivers.
 
-config RTC_LIB_KUNIT_TEST
-	tristate "KUnit test for RTC lib functions" if !KUNIT_ALL_TESTS
-	depends on KUNIT
-	default KUNIT_ALL_TESTS
-	help
-	  Enable this option to test RTC library functions.
-
-	  If unsure, say N.
-
 config RTC_NVMEM
 	bool "RTC non volatile storage support"
 	select NVMEM
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 0347645b021f..a3b336432df1 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -15,8 +15,6 @@ rtc-core-$(CONFIG_RTC_INTF_DEV)		+= dev.o
 rtc-core-$(CONFIG_RTC_INTF_PROC)	+= proc.o
 rtc-core-$(CONFIG_RTC_INTF_SYSFS)	+= sysfs.o
 
-obj-$(CONFIG_RTC_LIB_KUNIT_TEST)	+= test_rtc_lib.o
-
 # Keep the list ordered.
 
 obj-$(CONFIG_RTC_DRV_88PM80X)	+= rtc-88pm80x.o
diff --git a/drivers/rtc/test_rtc_lib.c b/drivers/rtc/test_rtc_lib.c
deleted file mode 100644
index 0eebad1fe2a0..000000000000
--- a/drivers/rtc/test_rtc_lib.c
+++ /dev/null
@@ -1,106 +0,0 @@
-// SPDX-License-Identifier: LGPL-2.1+
-
-#include <kunit/test.h>
-#include <linux/rtc.h>
-
-/*
- * Advance a date by one day.
- */
-static void advance_date(int *year, int *month, int *mday, int *yday, int *wday)
-{
-	*wday = (*wday + 1) % 7;
-
-	if (*mday != rtc_month_days(*month - 1, *year)) {
-		++*mday;
-		++*yday;
-		return;
-	}
-
-	*mday = 1;
-	if (*month != 12) {
-		++*month;
-		++*yday;
-		return;
-	}
-
-	*month = 1;
-	*yday  = 1;
-	++*year;
-}
-
-/*
- * Check every day in specified number of years interval starting on 1970-01-01
- * against the expected result.
- */
-static void rtc_time64_to_tm_test_date_range(struct kunit *test, int years)
-{
-	/*
-	 * years	= (years / 400) * 400 years
-	 *		= (years / 400) * 146097 days
-	 *		= (years / 400) * 146097 * 86400 seconds
-	 */
-	time64_t total_secs = ((time64_t)years) / 400 * 146097 * 86400;
-
-	int year	= 1900;
-	int month	= 1;
-	int mday	= 1;
-	int yday	= 1;
-	int wday	= 1; /* Jan 1st 1900 was a Monday */
-
-	struct rtc_time result;
-	time64_t secs;
-	const time64_t sec_offset = RTC_TIMESTAMP_BEGIN_1900 + ((1 * 60) + 2) * 60 + 3;
-
-	for (secs = 0; secs <= total_secs; secs += 86400) {
-
-		rtc_time64_to_tm(secs + sec_offset, &result);
-
-		#define FAIL_MSG "%d/%02d/%02d (%2d, %d) : %lld", \
-			year, month, mday, yday, wday, secs + sec_offset
-
-		KUNIT_ASSERT_EQ_MSG(test, year - 1900, result.tm_year, FAIL_MSG);
-		KUNIT_ASSERT_EQ_MSG(test, month - 1, result.tm_mon, FAIL_MSG);
-		KUNIT_ASSERT_EQ_MSG(test, mday, result.tm_mday, FAIL_MSG);
-		KUNIT_ASSERT_EQ_MSG(test, yday, result.tm_yday, FAIL_MSG);
-		KUNIT_ASSERT_EQ_MSG(test, 1, result.tm_hour, FAIL_MSG);
-		KUNIT_ASSERT_EQ_MSG(test, 2, result.tm_min, FAIL_MSG);
-		KUNIT_ASSERT_EQ_MSG(test, 3, result.tm_sec, FAIL_MSG);
-		KUNIT_ASSERT_EQ_MSG(test, wday, result.tm_wday, FAIL_MSG);
-
-		advance_date(&year, &month, &mday, &yday, &wday);
-	}
-}
-
-/*
- * Checks every day in a 160000 years interval starting on 1900-01-01
- * against the expected result.
- */
-static void rtc_time64_to_tm_test_date_range_160000(struct kunit *test)
-{
-	rtc_time64_to_tm_test_date_range(test, 160000);
-}
-
-/*
- * Checks every day in a 1000 years interval starting on 1900-01-01
- * against the expected result.
- */
-static void rtc_time64_to_tm_test_date_range_1000(struct kunit *test)
-{
-	rtc_time64_to_tm_test_date_range(test, 1000);
-}
-
-static struct kunit_case rtc_lib_test_cases[] = {
-	KUNIT_CASE(rtc_time64_to_tm_test_date_range_1000),
-	KUNIT_CASE_SLOW(rtc_time64_to_tm_test_date_range_160000),
-	{}
-};
-
-static struct kunit_suite rtc_lib_test_suite = {
-	.name = "rtc_lib_test_cases",
-	.test_cases = rtc_lib_test_cases,
-};
-
-kunit_test_suite(rtc_lib_test_suite);
-
-MODULE_DESCRIPTION("KUnit test for RTC lib functions");
-MODULE_LICENSE("GPL");

-- 
2.55.0

Re: [PATCH 4/4] rtc: test: Remove test_rtc_lib.c

[sashiko-bot]

> Now that rtc_time64_to_tm() is only a thin wrapper around time64_to_tm()
> the dedicated test is not necessary anymore. time64_to_tm() is already
> tested with a similar test in kernel/time/time_test.c
> 
> Remove it.
> 
> Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-time-time64-to-tm-v1-0-660be972adfc@linutronix.de?part=4