[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <539996AA.6020205@ahsoftware.de>
Date: Thu, 12 Jun 2014 14:01:46 +0200
From: Alexander Holler <holler@...oftware.de>
To: John Stultz <john.stultz@...aro.org>,
John Whitmore <arigead@...il.com>
CC: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alessandro Zummo <a.zummo@...ertech.it>
Subject: Re: rtc/hctosys.c Problem during kernel boot
Am 12.06.2014 01:53, schrieb John Stultz:
> 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!
Hmm, I'm still using this patches, now with 3.15 on a bunch of very
different x86 and arm boxes. So they are now tested since a year.
Unfortunately my expieriences with Linux kernel maintainers became even
worse and I'm not very eager to post patches. But if someone wants these
patches based on 3.15, feel free to notice me.
To get rid of hctosys, I have 3 patches, and 2 more to implement
rtc_read_timeval() for higher resolution clocks.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists