Re: [RFC][PATCH] Unify interface to persistent CMOS/RTC/whatever clock

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

By the way, one furher observation:

> > Presumably this is stuff that should be done by the RTC class resume()
> > method, probably for the CONFIG_RTC_HCTOSYS_DEVICE clock (though there
> > could be a better RTC ... one that's being NTP-corrected).  That'd
> > be no sooner than 2.6.19, which adds new class-level suspend()/resume()
> > calls to help offload individual drivers.
> 
> Hrm. I'm a bit skeptical that the RTC resume code should update the
> timekeeping code instead of the timekeeping code doing it.

But how could timekeeping code know when the RTC is accessible again?

It might be unusable until after e.g. an I2C controller and then the RTC
are resumed (and maybe a parent to the I2C controller) ... the class
resume mechanism piggybacks on the normal resume sequencing, so doing it
that way would automatically resolve that issue.


> It seems that 
> it would cause additional complexity (what if there are two RTC
> devices?) and would still have some of the suspend/resume ordering
> issues I'm worried about.

The RTC framework currently "knows" which RTC is used for the hctosys
update, so that approach can be addressed by saving a single pointer
and adding some class suspend()/resume() code to test it.  No complexity
necessary; if it's good enough to set the initial system time, it's
good enough to set it again after resume.  (And maybe all the RTCs
should be getting NTP updates, not just one of them ...)

I think that if you keep in mind that scenario -- I2C used to access
the RTC clock -- and make sure it works, you'll notice a few details
of your current approach that need to be changed.

In particular, it is impossible for any sys_device's driver resume()
to access I2C (since that resume is done with irqs disabled, while i2c
controllers normally require irqs to run); but that's what the current
version of timekeeping_resume() in your patch would be doing.

- Dave