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

From: Alexandre Belloni
Date: Sun Oct 20 2024 - 16:18:43 EST


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