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
