On 06/11/2019 15:37:49-0800, Steve Muckle wrote:

On 11/6/19 3:19 PM, Alexandre Belloni wrote:

quoted

On 06/11/2019 11:46:25-0800, Steve Muckle wrote:

quoted

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?

quoted

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.


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