[PATCH 6.15.y 0/2] rtc: backport support for handling dates before 1970

[PATCH 6.15.y 0/2] rtc: backport support for handling dates before 1970

[Uwe Kleine-König]

Hello,

as described in the commit log of the two commits the rtc-mt6397 driver
relies on these fixes as soon as it should store dates later than
2027-12-31. On one of the patches has a Fixes line, so this submission
is done to ensure that both patches are backported.

The patches sent in reply to this mail are (trivial) backports to
v6.15.1, they should get backported to the older stable kernels, too, to
(somewhat) ensure that in 2028 no surprises happen. `git am` is able to
apply the patches as is to 6.14.y, 6.12.y, 6.6.y, 6.1.y and 5.15.y.

5.10 and 5.4 need an adaption, I didn't look into that yet but can
follow up with backports for these.

The two fixes were accompanied by 3 test updates:

	46351921cbe1 ("rtc: test: Emit the seconds-since-1970 value instead of days-since-1970")
	da62b49830f8 ("rtc: test: Also test time and wday outcome of rtc_time64_to_tm()")
	ccb2dba3c19f ("rtc: test: Test date conversion for dates starting in 1900")

that cover one of the patches. Would you consider it sensible to
backport these, too?

Best regards
Uwe


Alexandre Mergnat (2):
  rtc: Make rtc_time64_to_tm() support dates before 1970
  rtc: Fix offset calculation for .start_secs < 0

 drivers/rtc/class.c |  2 +-
 drivers/rtc/lib.c   | 24 +++++++++++++++++++-----
 2 files changed, 20 insertions(+), 6 deletions(-)


base-commit: 3ef49626da6dd67013fc2cf0a4e4c9e158bb59f7
-- 
2.47.2

[PATCH 6.15.y 1/2] rtc: Make rtc_time64_to_tm() support dates before 1970

[Uwe Kleine-König]

From: Alexandre Mergnat <amergnat@baylibre.com>

commit 7df4cfef8b351fec3156160bedfc7d6d29de4cce upstream.

Conversion of dates before 1970 is still relevant today because these
dates are reused on some hardwares to store dates bigger than the
maximal date that is representable in the device's native format.
This prominently and very soon affects the hardware covered by the
rtc-mt6397 driver that can only natively store dates in the interval
1900-01-01 up to 2027-12-31. So to store the date 2028-01-01 00:00:00
to such a device, rtc_time64_to_tm() must do the right thing for
time=-2208988800.

Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-1-2b2f7e3f9349@baylibre.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
 drivers/rtc/lib.c | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/lib.c b/drivers/rtc/lib.c
index fe361652727a..13b5b1f20465 100644
--- a/drivers/rtc/lib.c
+++ b/drivers/rtc/lib.c
@@ -46,24 +46,38 @@ 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.
- *		(Must be positive.)
+ *		Works for values since at least 1900
  * @tm:		Pointer to the struct rtc_time.
  */
 void rtc_time64_to_tm(time64_t time, struct rtc_time *tm)
 {
-	unsigned int secs;
-	int days;
+	int days, 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;
 
-	/* time must be positive */
+	/*
+	 * Get days and seconds while preserving the sign to
+	 * handle negative time values (dates before 1970-01-01)
+	 */
 	days = div_s64_rem(time, 86400, &secs);
 
+	/*
+	 * We need 0 <= secs < 86400 which isn't given for negative
+	 * values of time. Fixup accordingly.
+	 */
+	if (secs < 0) {
+		days -= 1;
+		secs += 86400;
+	}
+
 	/* day of the week, 1970-01-01 was a Thursday */
 	tm->tm_wday = (days + 4) % 7;
+	/* Ensure tm_wday is always positive */
+	if (tm->tm_wday < 0)
+		tm->tm_wday += 7;
 
 	/*
 	 * The following algorithm is, basically, Proposition 6.3 of Neri
@@ -93,7 +107,7 @@ void rtc_time64_to_tm(time64_t time, struct rtc_time *tm)
 	 * thus, is slightly different from [1].
 	 */
 
-	udays		= ((u32) days) + 719468;
+	udays		= days + 719468;
 
 	u32tmp		= 4 * udays + 3;
 	century		= u32tmp / 146097;
-- 
2.47.2

[PATCH 6.15.y 2/2] rtc: Fix offset calculation for .start_secs < 0

[Uwe Kleine-König]

From: Alexandre Mergnat <amergnat@baylibre.com>

commit fe9f5f96cfe8b82d0f24cbfa93718925560f4f8d upstream.

The comparison

        rtc->start_secs > rtc->range_max

has a signed left-hand side and an unsigned right-hand side.
So the comparison might become true for negative start_secs which is
interpreted as a (possibly very large) positive value.

As a negative value can never be bigger than an unsigned value
the correct representation of the (mathematical) comparison

        rtc->start_secs > rtc->range_max

in C is:

        rtc->start_secs >= 0 && rtc->start_secs > rtc->range_max

Use that to fix the offset calculation currently used in the
rtc-mt6397 driver.

Fixes: 989515647e783 ("rtc: Add one offset seconds to expand RTC range")
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-2-2b2f7e3f9349@baylibre.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
 drivers/rtc/class.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index b88cd4fb295b..b1a2be1f9e3b 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -326,7 +326,7 @@ static void rtc_device_get_offset(struct rtc_device *rtc)
 	 *
 	 * Otherwise the offset seconds should be 0.
 	 */
-	if (rtc->start_secs > rtc->range_max ||
+	if ((rtc->start_secs >= 0 && rtc->start_secs > rtc->range_max) ||
 	    rtc->start_secs + range_secs - 1 < rtc->range_min)
 		rtc->offset_secs = rtc->start_secs - rtc->range_min;
 	else if (rtc->start_secs > rtc->range_min)
-- 
2.47.2

Re: [PATCH 6.15.y 0/2] rtc: backport support for handling dates before 1970

[Greg KH]

On Fri, Jun 06, 2025 at 05:44:37PM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> as described in the commit log of the two commits the rtc-mt6397 driver
> relies on these fixes as soon as it should store dates later than
> 2027-12-31. On one of the patches has a Fixes line, so this submission
> is done to ensure that both patches are backported.
> 
> The patches sent in reply to this mail are (trivial) backports to
> v6.15.1, they should get backported to the older stable kernels, too, to
> (somewhat) ensure that in 2028 no surprises happen. `git am` is able to
> apply the patches as is to 6.14.y, 6.12.y, 6.6.y, 6.1.y and 5.15.y.
> 
> 5.10 and 5.4 need an adaption, I didn't look into that yet but can
> follow up with backports for these.
> 
> The two fixes were accompanied by 3 test updates:
> 
> 	46351921cbe1 ("rtc: test: Emit the seconds-since-1970 value instead of days-since-1970")
> 	da62b49830f8 ("rtc: test: Also test time and wday outcome of rtc_time64_to_tm()")
> 	ccb2dba3c19f ("rtc: test: Test date conversion for dates starting in 1900")
> 
> that cover one of the patches. Would you consider it sensible to
> backport these, too?

If you want to, sure, but normally people run the latest in-kernel
selftests for older kernel trees.

thanks,

greg k-h