Re: [PATCH] rtc: class: Make the time32 hctosys limit configurable

[Karl Mehltretter]

On Wed, Sep 16, 2026 at 08:56:02AM +0100, Arnd Bergmann wrote:
> > existing safeguard automatically and prevent restoring it without
> > re-enabling the legacy ABI.
> 
> I'm not following your logic here, what is the safeguard?

I meant the existing RTC cutoff. In my glibc test, accepting the
2040 RTC date changes time32 clock_gettime() from success to
EOVERFLOW.

> With a fixed C library, COMPAT_32BIT_TIME=n should act as a safeguard
> to ensure that no interfaces can be used that limit time to y2038
> and break unexpectedly in the future. The RTC_HCTOSYS interface

Should we try adding an option to build glibc and other libcs without
time32 interfaces? Looking at musl's source, its time32 clock_gettime()
wrapper also calls the time64 implementation and checks whether the
result fits [1].

> actually make it work. Since we have COMPAT_32BIT_TIME as a global
> option already, it makes a lot of sense to actually use it here
> as well.

Could we use COMPAT_32BIT_TIME for the default, but still allow the
limit to be enabled? I could split the update into two patches:

1. Add RTC_HCTOSYS_TIME32_LIMIT with default y, as posted. This keeps
   the existing RTC date acceptance by default.

2. Change the default, keeping the dependency unchanged:

       depends on RTC_HCTOSYS && !64BIT
       default COMPAT_32BIT_TIME

With RTC_HCTOSYS=y on a 32-bit kernel, the default would allow
post-2038 RTC dates when COMPAT_32BIT_TIME=n. Integrators could still
enable the limit without re-enabling legacy syscalls.

I suggest nominating the first patch for stable. Would default
COMPAT_32BIT_TIME also be suitable for stable?

[1] https://git.musl-libc.org/cgit/musl/tree/compat/time32/clock_gettime32.c

Thanks,
Karl