Re: [PATCH 3/3] rtc: rtc-hid-sensor-time; add option hctosys to settime at boot

From: Alexander Holler
Date: Thu Apr 25 2013 - 02:56:24 EST

Am 24.04.2013 23:14, schrieb Andrew Morton:
On Tue, 23 Apr 2013 17:47:20 +0200 Alexander Holler <holler@xxxxxxxxxxxxx> wrote:

"time_was_set_once" and have choosen one day just in case something
needs really long to boot (e.g. because of some lengthy fsck or whatever

A solution to both problems might be to change the logic for hctosys
completly to read the time when the first RTC device appears (or when
the device mentioned in CONFIG_RTC_HCTOSYS_DEVICE appears). But that
would require a change to hctosys or the RTC subsystem, which would
involve more patches and discussion. As rtc-hid-sensor-time currently
seems to be the only RTC with the above problems, I've gone the easy
route and only modified this driver.

Oh, damn. I've forgotten my example above with NTP. In that case setting
the time when the first RTC appears doesn't work.

So a general solution might be to set the system time when the first RTC
(or the one mentioned in CONFIG_RTC_HCTOSYS_DEVICE) appears AND nothing
else did set the time before.

To extend that idea a bit further, I think an option timewait (similiar
to rootwait) would be a nice to have.

If just time wouldn't be that rare ... ;)

Yes, some sort of notifier callout when the CONFIG_RTC_HCTOSYS_DEVICE
device is registered seems appropriate. I didn't understand why that
is problematic for NTP.

Getting all the lifetime/reference stuff right will be tricky :( Can't
shut down or unload a driver when it is on that notification list.

And it assumes that the CONFIG_RTC_HCTOSYS_DEVICE driver is all ready
to go when it registers itself. Hopefully that is true, but they
should be reviewed.

Adding the timewait thing sounds unpleasant - how to reliably tune the
interval for all possible users of your distro? We should aim to make
things synchronous, deterministic and

It all sounds like a moderate amount of work, but it would be great
to be able to fix this for all drivers, not just hid-sensor-time. That's
assuming that other drivers have the same issue - perhaps they don't,
but perhaps things can go wrong if the module loading order is wrong?

I've added John Stultz to cc as he seems to work on a similiar problem (to not set the time twice on resume).

I'm not sure what you meant with the notifiers, but wouldn't be a function which sets the time if nothing else did that before a solution?

I think about something like that (not real code):

static bool timeWasSet; // = 0

int setTimeIfNotSet(time, devicename)
if (timeWasSet || (devicename && CONFIG_RTC_HCTOSYS_DEVICE && devicename != CONFIG_RTC_HCTOSYS_DEVICE )
return -1;

timeWasSet = 1;
return 0;

That "timewait" kernel option I mentioned above then would be easy too:

void timewait(void)
while (!timeWasSet)

That setTimeIfNotSet() function could be called by the RTC subsystem whenever a new RTC will be registered and CONFIG_RTC_HCTOSYS is enabled (or on resume).
In regard to the persistent_clocks on x86 I know almost nothing. I didn't even knew they do exist before I've seen a discussion about HCTOSYS yesterday. I thought the RTC_CMOS driver is responsible for the time on x86. ;) Therfor I can't say anything about how things do work there.

Whats missing above is something which sets timeWasSet to 1 if userland (NTP or similiar) does set the time. That could be done always (in do_settimeofday) or e.g. by using a function pointer to do_settimeofday() which first points to a function which sets timeWasSet and later on points to do_settimeofday() directly.

Maybe it's all silly (I'm missing the big overview over time in the kernel), but thats what first entered my mind while thinking about how to avoid changing a time by an HID device if it was already set by userland/NTP or another clock (besides that trick in testing for system date < 1970-01-02 I've then used in my patch because it was easy to implement while not doing changes to timekeeping itself).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at