Re: rtc/hctosys.c Problem during kernel boot
From: John Whitmore
Date: Wed Jun 11 2014 - 21:08:11 EST
On Wed, Jun 11, 2014 at 04:53:55PM -0700, John Stultz wrote:
> On Wed, Jun 11, 2014 at 4:01 PM, John Whitmore <arigead@xxxxxxxxx> wrote:
> > I'm having a problem with a DS3234 SPI based RTC chip and rtc/hctosys.c on the
> > 3.10.29 kernel of the RaspberryPi. I'm not sure this is a bug or not but
> > thought I'd ask. I've enabled the kernel config option for HCTOSYS which, on
> > boot, should set the system's date/time to the value read from the RTC. I
> > tried tihs but it would never happen on the RPi. I eventually found in syslog
> > that the kernel boot is attempting to execute the hctosys functionality prior
> > to the SPI being initialised. As a result of this when hctosys is attempted
> > there is not /dev/rtc0 yet. A short time later the DS3234 RTC is initialised
> > but by then it's too late.
> >
> > Once the system has booted and I've logged in I can read and write to the RTC
> > and all seems good but /sys/class/rtc/rtc0/hctosys is '0' indicating that the
> > system time was not set on boot.
> >
> > There is a "deprecated" warning in the syslog coming from the spi of the board
> > file so perhaps that is the cause. So is this a bug? And if so what can I do
> > to resolve it. The hctosys is on a "late_initcall" so not sure of timing.
>
> Sigh. Yea, this issue was brought up previously, but we never got
> around to a solution that could be merged.
>
> Basically hctosys is late_init, but if the driver is a module, it
> might not be loaded in time. Adding hooks at module load time when
> RTCs are registered could be done, but then you have the issue that
> userspace might have set the clock via something like ntpdate, so
> HCTOSYS could then cause the clock to be less accurate.
>
> So we need to make the HCTOSYS functionality happen at RTC register
> time, but it needs to set the clock only if nothing has set the clock
> already. This requires a new timekeeeping interface - something like
> timekeeping_set_time_if_unset(), which atomically would set the time
> if it has never been set.
>
> You can read some of the previous discussion here:
> https://lkml.org/lkml/2013/6/17/533
>
Thanks a million for that information I'll have a look, as I might try and
resolve the issue.
> I'd be very interested in patches to resolve this!
>
> thanks
> -john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/