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

On Mon, Sep 14, 2026, at 23:25, Karl Mehltretter wrote:

On 32-bit systems with RTC_HCTOSYS enabled, rtc_hctosys() rejects
RTC dates whose seconds value exceeds INT_MAX, even when userspace
uses a 64-bit time_t. This leaves system time uninitialized by the RTC.

Commit b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow
time_t") introduced this limit to protect time32 userspace from future
RTC dates that can break boot. The same limit prevents systems with
time64 userspace from initializing the clock from valid post-2038 dates.

Hi Karl,

Thanks for revisiting this!

Add RTC_HCTOSYS_TIME32_LIMIT for 32-bit kernels, defaulting to y to
preserve the existing safeguard. Allow integrators to disable it once
their entire userspace, including init, supports post-2038 dates.
Warn on rejection with the RTC date and option name so users can
identify the cause and find the setting.

Keep the option independent of COMPAT_32BIT_TIME. Userspace with a
64-bit time_t may still need legacy syscalls for operations that do
not represent post-2038 dates.

What about the reverse: if COMPAT_32BIT_TIME is disabled, I don't
see why we'd want to allow turning this on, so maybe

+config RTC_HCTOSYS_TIME32_LIMIT
+	bool "Reject RTC dates after the 2038 cutoff"
+	depends on RTC_HCTOSYS && !64BIT && !COMPAT_32BIT_TIME

[Technically it would also make sense to enable the option on 64-bit
kernels running 32-bit userspace, which some users do to reduce
memory usage. However, we never supported that case and I'd rather
not start now.]

      Arnd