[PATCH v4 0/5] Fix pre-1970 date handling

[PATCH v4 0/5] Fix pre-1970 date handling

[Alexandre Mergnat]

This series fixes pre-1970 date handling in the RTC subsystem. The changes
are particularly important for MediaTek platforms using the rtc-mt6397
driver, which can only store dates from 1900-01-01 to 2027-12-31.

The handling of pre-1970 dates in time conversion functions is improved, which
is essential for hardware that must reuse earlier dates once their native format
limits are reached. Sign-related comparison issues causing incorrect offset
calculations are fixed, and the test infrastructure is enhanced to validate time
conversions across the entire date range.

These improvements ensure the RTC subsystem functions correctly when hardware
date limits are reached, particularly relevant as the rtc-mt6397 driver will
hit its upper limit in less than three years.

---
Changes in v4:
- Remove "rtc: mt6359: Add mt6357 support" to send it in another serie.
- Change title serie to "Fix pre-1970 date handling " because MT6357
  support is no more related to this.
- Remove "arm64: dts: mediatek: Set RTC start year property" because it
  is not requiered to have MTK RTC working.
- Remove "rtc: mt6397: Remove start time parameters".
- Rework time comparison fix to avoid cast.
- Remove change in rtc_valid_tm.
- Improve rtc_time64_to_tm change for readability and efficiency.
- Extend conversion test cover to reach 1900 year value.
- Link to v3: https://lore.kernel.org/r/20250109-enable-rtc-v3-0-f003e8144419@baylibre.com

Changes in v3:
- Rebase on top of rtc-6.15
- Added explicit start-year property in DTSIs for MT6357, MT6358, and
  MT6359 PMIC RTCs to ensure consistent values between hardware
  registers and the RTC framework.
- Removed hardcoded offset and start_secs parameter in mt6397 driver
  in favor of using the DTS start-year property.
- Fixed type comparison issues between signed time64_t and unsigned
  range values to correctly handle dates before 1970.
- Added proper handling of negative time values (pre-1970 dates) in
  time conversion functions.
- Modified rtc_time64_to_tm() to correctly handle negative timestamp
  values.
- Removed the tm_year < 70 restriction in rtc_valid_tm() to allow
  pre-1970 dates to be validated correctly .
- Link to v2: https://lore.kernel.org/all/20250109-enable-rtc-v2-0-d7ddc3e73c57@baylibre.com/

Changes in v2:
- Split the patch to have:
  - Add MT6357 support
  - Fix hwclock issue
- Handle the year offset in another way, but the V1 way still viable.
- Link to v1: https://lore.kernel.org/r/20250109-enable-rtc-v1-0-e8223bf55bb8@baylibre.com

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

Uwe Kleine-König (3):
      rtc: test: Emit the seconds-since-1970 value instead of days-since-1970
      rtc: test: Also test time and wday outcome of rtc_time64_to_tm()
      rtc: test: Test date conversion for dates starting in 1900

 drivers/rtc/class.c    |  2 +-
 drivers/rtc/lib.c      | 24 +++++++++++++++++++-----
 drivers/rtc/lib_test.c | 27 ++++++++++++++++-----------
 3 files changed, 36 insertions(+), 17 deletions(-)
---
base-commit: 424dfcd441f035769890e6d1faec2081458627b9
change-id: 20250109-enable-rtc-b2ff435af2d5

Best regards,
-- 
Alexandre Mergnat <amergnat@baylibre.com>

[PATCH v4 1/5] rtc: Make rtc_time64_to_tm() support dates before 1970

[Alexandre Mergnat]

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>
---
 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 fe361652727a3f8cb116c78b5aeea74eb90080b5..13b5b1f2046510d1a552473c441b89e23faa6793 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.25.1

[PATCH v4 2/5] rtc: Fix offset calculation for .start_secs < 0

[Alexandre Mergnat]

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>
---
 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 e31fa0ad127e9545afac745a621d4ccbcd5fca28..a0afdeaac270f026734be8785e8ed7e1272b2348 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -327,7 +327,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.25.1

[PATCH v4 3/5] rtc: test: Emit the seconds-since-1970 value instead of days-since-1970

[amergnat]

From: Uwe Kleine-König <u.kleine-koenig@baylibre.com>

This is easier to handle because you can just consult date(1) to convert
between a seconds-since-1970 value and a date string:

	$ date --utc -d @3661
	Thu Jan  1 01:01:01 AM UTC 1970

	$ date -d "Jan 1 12:00:00 AM UTC 1900" +%s
	-2208988800

The intended side effect is that this prepares the test for dates before
1970. The division of a negative value by 86400 doesn't result in the
desired days-since-1970 value as e.g. secs=-82739 should map to days=-1.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
---
 drivers/rtc/lib_test.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/rtc/lib_test.c b/drivers/rtc/lib_test.c
index c30c759662e39b48e6fedd37073b656e0de1336b..c0faddc04c9bbcd421cbdc030c4a073056c6a9a6 100644
--- a/drivers/rtc/lib_test.c
+++ b/drivers/rtc/lib_test.c
@@ -46,16 +46,13 @@ static void rtc_time64_to_tm_test_date_range(struct kunit *test, int years)
 
 	struct rtc_time result;
 	time64_t secs;
-	s64 days;
 
 	for (secs = 0; secs <= total_secs; secs += 86400) {
 
 		rtc_time64_to_tm(secs, &result);
 
-		days = div_s64(secs, 86400);
-
 		#define FAIL_MSG "%d/%02d/%02d (%2d) : %lld", \
-			year, month, mday, yday, days
+			year, month, mday, yday, secs
 
 		KUNIT_ASSERT_EQ_MSG(test, year - 1900, result.tm_year, FAIL_MSG);
 		KUNIT_ASSERT_EQ_MSG(test, month - 1, result.tm_mon, FAIL_MSG);

-- 
2.25.1

[PATCH v4 4/5] rtc: test: Also test time and wday outcome of rtc_time64_to_tm()

[amergnat]

From: Uwe Kleine-König <u.kleine-koenig@baylibre.com>

To cover calculation of the time and wday in the rtc kunit test also check
tm_hour, tm_min, tm_sec and tm_wday of the rtc_time calculated by
rtc_time64_to_tm().

There are no surprises, the two tests making use of
rtc_time64_to_tm_test_date_range() continue to succeed.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
---
 drivers/rtc/lib_test.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/lib_test.c b/drivers/rtc/lib_test.c
index c0faddc04c9bbcd421cbdc030c4a073056c6a9a6..b1ac0701d42e5562b8eae5b191012c8b56a06902 100644
--- a/drivers/rtc/lib_test.c
+++ b/drivers/rtc/lib_test.c
@@ -6,8 +6,10 @@
 /*
  * Advance a date by one day.
  */
-static void advance_date(int *year, int *month, int *mday, int *yday)
+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;
@@ -43,23 +45,29 @@ static void rtc_time64_to_tm_test_date_range(struct kunit *test, int years)
 	int month	= 1;
 	int mday	= 1;
 	int yday	= 1;
+	int wday	= 4; /* Jan 1st 1970 was a Thursday */
 
 	struct rtc_time result;
 	time64_t secs;
+	const time64_t sec_offset = ((1 * 60) + 2) * 60 + 3;
 
 	for (secs = 0; secs <= total_secs; secs += 86400) {
 
-		rtc_time64_to_tm(secs, &result);
+		rtc_time64_to_tm(secs + sec_offset, &result);
 
-		#define FAIL_MSG "%d/%02d/%02d (%2d) : %lld", \
-			year, month, mday, yday, secs
+		#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);
+		advance_date(&year, &month, &mday, &yday, &wday);
 	}
 }
 

-- 
2.25.1

[PATCH v4 5/5] rtc: test: Test date conversion for dates starting in 1900

[amergnat]

From: Uwe Kleine-König <u.kleine-koenig@baylibre.com>

While the RTC framework intends to only handle dates after 1970 for
consumers, time conversion must also work for earlier dates to cover
e.g. storing dates beyond an RTC's range_max. This is most relevant for
the rtc-mt6397 driver that has

	range_min = RTC_TIMESTAMP_BEGIN_1900;
	range_max = mktime64(2027, 12, 31, 23, 59, 59);

and so needs working support for timestamps in 1900 starting in less than
three years.

So shift the tested interval of timestamps to also cover years 1900 to
1970.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
---
 drivers/rtc/lib_test.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/lib_test.c b/drivers/rtc/lib_test.c
index b1ac0701d42e5562b8eae5b191012c8b56a06902..0eebad1fe2a0983c0009626dac526fa07d27f6b6 100644
--- a/drivers/rtc/lib_test.c
+++ b/drivers/rtc/lib_test.c
@@ -41,15 +41,15 @@ static void rtc_time64_to_tm_test_date_range(struct kunit *test, int years)
 	 */
 	time64_t total_secs = ((time64_t)years) / 400 * 146097 * 86400;
 
-	int year	= 1970;
+	int year	= 1900;
 	int month	= 1;
 	int mday	= 1;
 	int yday	= 1;
-	int wday	= 4; /* Jan 1st 1970 was a Thursday */
+	int wday	= 1; /* Jan 1st 1900 was a Monday */
 
 	struct rtc_time result;
 	time64_t secs;
-	const time64_t sec_offset = ((1 * 60) + 2) * 60 + 3;
+	const time64_t sec_offset = RTC_TIMESTAMP_BEGIN_1900 + ((1 * 60) + 2) * 60 + 3;
 
 	for (secs = 0; secs <= total_secs; secs += 86400) {
 
@@ -72,7 +72,7 @@ static void rtc_time64_to_tm_test_date_range(struct kunit *test, int years)
 }
 
 /*
- * Checks every day in a 160000 years interval starting on 1970-01-01
+ * 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)
@@ -81,7 +81,7 @@ static void rtc_time64_to_tm_test_date_range_160000(struct kunit *test)
 }
 
 /*
- * Checks every day in a 1000 years interval starting on 1970-01-01
+ * 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)

-- 
2.25.1

Re: [PATCH v4 0/5] Fix pre-1970 date handling

[Alexandre Mergnat]

Hi Angelo,

I failed to Cc: you for this new revision because it doesn't touch the mtk rtc driver any more. 
Still you might be interested as it fixes the issues for this driver. I'm looking forward to feedback.

On 28/04/2025 12:06, Alexandre Mergnat wrote:
> This series fixes pre-1970 date handling in the RTC subsystem. The changes
> are particularly important for MediaTek platforms using the rtc-mt6397
> driver, which can only store dates from 1900-01-01 to 2027-12-31.
> 
> The handling of pre-1970 dates in time conversion functions is improved, which
> is essential for hardware that must reuse earlier dates once their native format
> limits are reached. Sign-related comparison issues causing incorrect offset
> calculations are fixed, and the test infrastructure is enhanced to validate time
> conversions across the entire date range.
> 
> These improvements ensure the RTC subsystem functions correctly when hardware
> date limits are reached, particularly relevant as the rtc-mt6397 driver will
> hit its upper limit in less than three years.
> 
> ---
> Changes in v4:
> - Remove "rtc: mt6359: Add mt6357 support" to send it in another serie.
> - Change title serie to "Fix pre-1970 date handling " because MT6357
>    support is no more related to this.
> - Remove "arm64: dts: mediatek: Set RTC start year property" because it
>    is not requiered to have MTK RTC working.
> - Remove "rtc: mt6397: Remove start time parameters".
> - Rework time comparison fix to avoid cast.
> - Remove change in rtc_valid_tm.
> - Improve rtc_time64_to_tm change for readability and efficiency.
> - Extend conversion test cover to reach 1900 year value.
> - Link to v3: https://lore.kernel.org/r/20250109-enable-rtc-v3-0-f003e8144419@baylibre.com
> 
> Changes in v3:
> - Rebase on top of rtc-6.15
> - Added explicit start-year property in DTSIs for MT6357, MT6358, and
>    MT6359 PMIC RTCs to ensure consistent values between hardware
>    registers and the RTC framework.
> - Removed hardcoded offset and start_secs parameter in mt6397 driver
>    in favor of using the DTS start-year property.
> - Fixed type comparison issues between signed time64_t and unsigned
>    range values to correctly handle dates before 1970.
> - Added proper handling of negative time values (pre-1970 dates) in
>    time conversion functions.
> - Modified rtc_time64_to_tm() to correctly handle negative timestamp
>    values.
> - Removed the tm_year < 70 restriction in rtc_valid_tm() to allow
>    pre-1970 dates to be validated correctly .
> - Link to v2: https://lore.kernel.org/all/20250109-enable-rtc-v2-0-d7ddc3e73c57@baylibre.com/
> 
> Changes in v2:
> - Split the patch to have:
>    - Add MT6357 support
>    - Fix hwclock issue
> - Handle the year offset in another way, but the V1 way still viable.
> - Link to v1: https://lore.kernel.org/r/20250109-enable-rtc-v1-0-e8223bf55bb8@baylibre.com
> 
> ---
> Alexandre Mergnat (2):
>        rtc: Make rtc_time64_to_tm() support dates before 1970
>        rtc: Fix offset calculation for .start_secs < 0
> 
> Uwe Kleine-König (3):
>        rtc: test: Emit the seconds-since-1970 value instead of days-since-1970
>        rtc: test: Also test time and wday outcome of rtc_time64_to_tm()
>        rtc: test: Test date conversion for dates starting in 1900
> 
>   drivers/rtc/class.c    |  2 +-
>   drivers/rtc/lib.c      | 24 +++++++++++++++++++-----
>   drivers/rtc/lib_test.c | 27 ++++++++++++++++-----------
>   3 files changed, 36 insertions(+), 17 deletions(-)
> ---
> base-commit: 424dfcd441f035769890e6d1faec2081458627b9
> change-id: 20250109-enable-rtc-b2ff435af2d5
> 
> Best regards,

-- 
Regards,
Alexandre

Re: [PATCH v4 1/5] rtc: Make rtc_time64_to_tm() support dates before 1970

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

Hello Alexandre,

On Mon, Apr 28, 2025 at 12:06:47PM +0200, Alexandre Mergnat wrote:
> 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>

Given this problem starts to bite in 2028 I'd like to see this (and the
next) patch backported to stable. If you want a Fixes: line, maybe
34bbdc12d04e ("rtc: mt6359: Add RTC hardware range and add support for
start-year") is sensible here as this is the commit that introduced the
requirement to handle negative timestamps. (The drivers that made use
of the offset feature already before that commit all had
.range_min >= 0, and so are not affected by this problem.)

With my Debian kernel team member hat on, I even welcome
34bbdc12d04e2f18a2ca96351c59e40b62da3314 being backported to 6.12.y
given that the next Debian stable release ("trixie") will use 6.12.y and
will likely matter longer than 2027.

Apart from that:

Reviewed-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v4 2/5] rtc: Fix offset calculation for .start_secs < 0

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

Hello,

On Mon, Apr 28, 2025 at 12:06:48PM +0200, Alexandre Mergnat wrote:
> 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>

Thanks
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v4 1/5] rtc: Make rtc_time64_to_tm() support dates before 1970

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]

Hello Alexandre,

On Mon, Apr 28, 2025 at 06:59:33PM +0200, Uwe Kleine-König wrote:
> On Mon, Apr 28, 2025 at 12:06:47PM +0200, Alexandre Mergnat wrote:
> > 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>
> 
> Given this problem starts to bite in 2028 I'd like to see this (and the
> next) patch backported to stable. If you want a Fixes: line, maybe
> 34bbdc12d04e ("rtc: mt6359: Add RTC hardware range and add support for
> start-year") is sensible here as this is the commit that introduced the
> requirement to handle negative timestamps. (The drivers that made use
> of the offset feature already before that commit all had
> .range_min >= 0, and so are not affected by this problem.)

Given that we're already at v6.15-rc5 I wonder if there is a chance to
get these changes reviewed and applied before v6.15. Would a pull
request help you? If yes, should it only contain the fixes, or also the
updated tests?

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v4 1/5] rtc: Make rtc_time64_to_tm() support dates before 1970

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]

Hello Alexandre,

On Tue, May 06, 2025 at 09:58:32AM +0200, Uwe Kleine-König wrote:
> On Mon, Apr 28, 2025 at 06:59:33PM +0200, Uwe Kleine-König wrote:
> > On Mon, Apr 28, 2025 at 12:06:47PM +0200, Alexandre Mergnat wrote:
> > > 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>
> > 
> > Given this problem starts to bite in 2028 I'd like to see this (and the
> > next) patch backported to stable. If you want a Fixes: line, maybe
> > 34bbdc12d04e ("rtc: mt6359: Add RTC hardware range and add support for
> > start-year") is sensible here as this is the commit that introduced the
> > requirement to handle negative timestamps. (The drivers that made use
> > of the offset feature already before that commit all had
> > .range_min >= 0, and so are not affected by this problem.)
> 
> Given that we're already at v6.15-rc5 I wonder if there is a chance to
> get these changes reviewed and applied before v6.15. Would a pull
> request help you? If yes, should it only contain the fixes, or also the
> updated tests?

We missed to get the patches in for v6.15 :-\

I see you recently applied some patches in your rtc-next branch, but
this series isn't included. That makes me wonder if you still have it on
your radar.

My offer to provide you a pull request still stands, just tell me if I
should include the tests if you want me to provide such a PR.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v4 0/5] Fix pre-1970 date handling

[Alexandre Belloni]

On Mon, 28 Apr 2025 12:06:46 +0200, Alexandre Mergnat wrote:
> This series fixes pre-1970 date handling in the RTC subsystem. The changes
> are particularly important for MediaTek platforms using the rtc-mt6397
> driver, which can only store dates from 1900-01-01 to 2027-12-31.
> 
> The handling of pre-1970 dates in time conversion functions is improved, which
> is essential for hardware that must reuse earlier dates once their native format
> limits are reached. Sign-related comparison issues causing incorrect offset
> calculations are fixed, and the test infrastructure is enhanced to validate time
> conversions across the entire date range.
> 
> [...]

Applied, thanks!

[1/5] rtc: Make rtc_time64_to_tm() support dates before 1970
      https://git.kernel.org/abelloni/c/7df4cfef8b35
[2/5] rtc: Fix offset calculation for .start_secs < 0
      https://git.kernel.org/abelloni/c/fe9f5f96cfe8
[3/5] rtc: test: Emit the seconds-since-1970 value instead of days-since-1970
      https://git.kernel.org/abelloni/c/46351921cbe1
[4/5] rtc: test: Also test time and wday outcome of rtc_time64_to_tm()
      https://git.kernel.org/abelloni/c/da62b49830f8
[5/5] rtc: test: Test date conversion for dates starting in 1900
      https://git.kernel.org/abelloni/c/ccb2dba3c19f

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com