Re: rtc: how should I handle an invalid state?

[David Brownell <david-b@pacbell.net>]

On Tuesday 29 April 2008, Uwe Kleine-König wrote:
> The problem is that hwclock tries to read the current time before
> setting the new one.  And if that fails, it doesn't update the rtc.

Which version of hwclock?  That does seem like a bug in that
particular version.  If it's in util-linux-ng or busybox,
please send in a patch.  I don't think anyone should be
deploying *new* systems using *old/unmaintained* util-linux.

I'll suspect this is on some util-linux version, since I'm
quite sure that I've had busybox based systems that don't
show this misbehavior.  Haven't had occasion to use non-PC
RTCs with a util-linux-ng version; I wouldn't call a bug in
such combinations a kernel regression, either...

I think the preferred solution never returns invalid times as
valid.  Some RTC drivers do this themselves:

        int my_rtc_read_time(struct device *dev, struct rtc_time *time)
	{
		... read the hardware into *time ...
		return rtc_valid_tm(time);
	}

Or rtc_valid_tm() might be checked in the RTC framework glue,
to provide more uniform behavior at the framework level.

Either way, it's not unknown that an un-initialized RTC have
undefined state, and thus return invalid times until they've
been set (using wall clock, NTP, or whatever).

- Dave