Re: [PATCH] rtc: class: support hctosys from modular RTC drivers

From: Steve Muckle
Date: Fri Jan 31 2020 - 13:35:06 EST


On 12/27/19 12:26 PM, Steve Muckle wrote:
On 11/15/19 5:36 AM, Alexandre Belloni wrote:
On 06/11/2019 15:37:49-0800, Steve Muckle wrote:
On 11/6/19 3:19 PM, Alexandre Belloni wrote:
On 06/11/2019 11:46:25-0800, Steve Muckle wrote:
Due to distribution constraints it may not be possible to statically
compile the required RTC driver into the kernel.

Expand RTC_HCTOSYS support to cover all RTC devices (statically compiled
or not) by checking at the end of RTC device registration whether the
time should be synced.


This does not really help distributions because most of them will still
have "rtc0" hardcoded and rtc0 is often the rtc that shouldn't be used.

Just for my own edification, why is that? Is rtc0 normally useless on PC for
some reason?


On PC, rtc0 is probably fine which is not the case for other
architectures where rtc0 is the SoC RTC and is often not battery backed.

On the platforms I'm working with I believe it can be assured that rtc0 will
be the correct rtc. That doesn't help typical distributions though.

What about a kernel parameter to optionally override the rtc hctosys device
at runtime?


What about keeping that in userspace instead which is way easier than
messing with kernel parameters?

This should ideally happen before file systems are mounted so I don't
see many alternatives for communicating which RTC should be used.
Android uses the kernel command line for userspace parameters as well
and that's an option but that defeats part of the value of doing it in
userspace IMO. There's also device tree but I'm not sure this belongs there.

Hctosys is also saving and restoring the system time on suspend/resume.
It seems more efficient to me to do this (which happens very frequently
on an Android device) in the kernel as opposed to in userspace.

If I set the initial system time from the rtc in userspace but continue
to rely on the hctosys suspend/resume code, as it stands there will be a
window after the rtc driver is loaded but before the system time is set
where if suspend is entered, the correct time in the rtc will be lost.
>
Can't you move away from HCTOSYS and do the correct thing in userspace
instead of the crap hctosys is doing?

Yes, I just figured it's a small change, and if hctosys can be made to work
might as well use that.

The fact is that hctosys is more related to time keeping than it is to
the RTC subsytem. It also does a very poor job setting the system time
because adding 0.5s is not the smartest thing to do. The rtc granularity
is indeed 1 second but is can be very precisely set.
>
No argument with that, but millions of devices successfully rely on it
today. AFAICT this simple patch doesn't make anything worse. Together
with a change to support a kernel parameter for runtime rtc selection,
it should allow RTC drivers to be modularized on many systems. Can it be
adopted as a stopgap measure?

Hi Alexandre, ping...