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? > > 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
