RTC hctosys disabled for 32-bit systems

[Reinier Kuipers]

Hello all,

I'm working to fix the y2038 issue for an existing sama5d3-based
product. This involves updating the kernel and glibc to appropriate
versions (5.10 and 2.35.1 respectively) and I got things running up to
a state where, from userspace, both date and hwclock commands have no
issue accepting dates beyond 2038. However, even with the RTC_HCTOSYS
and RTC_HCTOSYS_DEVICE options configured correctly, the RTC driver
fails to initialize the system clock at bootup.

Some digging in rtc/class.c::rtc_hctosys() indicates that
do_settimeofday64() is deliberately not executed on systems with
BITS_PER_LONG==32 and a second counter higher than INT_MAX. I assumed
that the work on 64-bits timestamps was already fully implemented for
32-bit systems as well, so my gut feel is that this
BITS_PER_LONG/INT_MAX check has become unnecessary. A test build with
these checks disabled results in correct time initialization at bootup
with, at a glance, no adverse effects. Does anybody here know whether
do_settimeofday64()  is robust on 32-bit systems or that the checks
are still required to prevent further breakage?

Kind regards,
Reinier