Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit

[Alexandre Belloni]

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