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

[Alexandre Belloni <alexandre.belloni@bootlin.com>]

On 24/09/2026 17:07:30+0200, Arnd Bergmann wrote:
> On Tue, Sep 22, 2026, at 23:37, Alexandre Belloni wrote:
> > On 19/09/2026 11:16:29+0200, Arnd Bergmann wrote:
> >> On Sat, Sep 19, 2026, at 02:10, Karl Mehltretter wrote:
> >>
> >> config RTC_HCTOSYS_TIME32_LIMIT
> >> 	bool "Reject RTC dates after the 2038 cutoff"
> >> 	depends on RTC_HCTOSYS && !64BIT && COMPAT_32BIT_TIME
> >> 	default y
> >> 
> >> to completely disallow it. I think we should wait for Alexandre
> >> to comment here, as it's his subsystem in the end and I'm sure
> >> he has an opinion on the matter.
> >> 
> >
> > I gave it some thought for the past month as this is an issue that is
> > regularly brought up.
> >
> > The first thing is that this is an issue that disappears as soon as
> > RTC_HCTOSYS is not used. RTC_HCTOSYS has plenty of issue and one of
> > those is that is doesn't actually work well with NTP. There is a fix for
> > this and it would slow down every boot by a second or two.
> 
> Sure, simply disallowing RTC_HCTOSYS on any build that contains support
> for time32 userspace would also avoid this.
> 
> > The main issue is that systemd decided to mandate RTC_HCTOSYS when
> > raising up the issue, the answer is that it is unacceptable to have logs
> > that are not properly dated until userspace sets the system time. But
> > letting userspace set the system time simply solves the issue as it will
> > always set a time that it can handle, even if not correct.
> 
> Not sure what exactly you are suggesting here. Do you mean we should
> try again to address this in systemd in order to no longer need
> the RTC_HCTOSYS hack?
> 

Well I guess we'll get the same answer that this is too late in the boot
process.

My proposed solution is to have a way to tell the kernel what size of
time_t userspace actually supports as there is no way to automatically
detect it. That's why I was thinking a kernel cmdline parameter would
fit. This would allow us to be 100% correct.

Else, I'm fine with your last proposal. I guess this would leave us with
two unhandled cases:
 - 64bit systems with 32 bit userspace that you said we don't want to
   support
 - 32bit systems with 64bit time_t userspace that would not work
   properly with the default configuration.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com