On 05/10/2024 14:23:28+1000, Finn Thain wrote:
On Thu, 3 Oct 2024, Alexandre Belloni wrote:
... while you are it, can you use m48t59->rtc->start_secs and
m48t59->rtc->set_start_time in probe instead of offsetting tm_year in
read_time/set_time so we can later use device tree or any other
mechanism to extend the range?
That didn't work out as I'd hoped. I booted a patched kernel (diff below)
under qemu-system-sparc64:
~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do
date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
Thu Jan 1 01:01:00 UTC 1970
Thu Jan 1 01:01:00 1970 0.000000 seconds
Fri Jan 1 01:01:00 UTC 1971
Tue Nov 24 18:32:44 1998 0.000000 seconds
Fri Jan 1 01:01:00 UTC 1999
Tue Nov 24 18:32:44 2026 0.000000 seconds
Sat Jan 1 01:01:00 UTC 2000
Sun Jan 2 23:29:16 2000 0.000000 seconds
Mon Jan 1 01:01:00 UTC 2024
Tue Jan 2 23:29:16 2024 0.000000 seconds
Wed Jan 1 01:01:00 UTC 2025
Thu Jan 2 23:29:16 2025 0.000000 seconds
Sun Jan 1 01:01:00 UTC 2068
hwclock: RTC_SET_TIME: Numerical result out of range
Tue Jan 1 01:01:00 UTC 2069
hwclock: RTC_SET_TIME: Numerical result out of range
~ #
Here's the result from an unpatched kernel (v6.11):
~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do
date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
Thu Jan 1 01:01:00 UTC 1970
Thu Jan 1 01:01:00 1970 0.000000 seconds
Fri Jan 1 01:01:00 UTC 1971
Fri Jan 1 01:01:00 1971 0.000000 seconds
Fri Jan 1 01:01:00 UTC 1999
Fri Jan 1 01:01:01 1999 0.000000 seconds
Sat Jan 1 01:01:00 UTC 2000
Sat Jan 1 01:01:00 2000 0.000000 seconds
Mon Jan 1 01:01:00 UTC 2024
Mon Jan 1 01:01:00 2024 0.000000 seconds
Wed Jan 1 01:01:00 UTC 2025
Wed Jan 1 01:01:00 2025 0.000000 seconds
Sun Jan 1 01:01:00 UTC 2068
hwclock: RTC_RD_TIME: Invalid argument
Tue Jan 1 01:01:00 UTC 2069
hwclock: RTC_RD_TIME: Invalid argument
~ #
I'm afraid I don't see how we might avoid adding/subtracting in
read_time/set_time given that we must avoid messing up the present date
when users boot into an upgraded kernel.
I'm pretty sure this is avoidable as this is exactly what the offset
mechanism is trying to achieve. I guess the issue is in the RTC core
because both range_min and start_secs are negative which has never been
tested. My plan was to have unit tests for this but this never
happened...
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
