Re: rtc/hctosys.c Problem during kernel boot

[John Stultz]

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

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/