On Tue, May 6, 2008 at 5:40 PM, Maciej W. Rozycki <macro@xxxxxxxxxxxxxx> wrote: > This is a generic implementation of rtc_read_persistent_clock() and > rtc_update_persistent_clock() suitable for platforms to be used for > read_persistent_clock() and update_persistent_clock() calls. An RTC > device selected by the user with the RTC_HCTOSYS_DEVICE option is used. > > As rtc_read_persistent_clock() is not available at the time > timekeeping_init() is called, it will now be disabled if the class device > is to be used as a reference. In this case rtc_hctosys(), already > present, will be used to set up the system time at the late initcall time. > This call has now been rewritten to make use of > rtc_read_persistent_clock(). Hrmm. So how is this going to work with suspend and resume? Ideally, on resume we want to update the clock before interrupts are reenabled so we don't get stale time values post-resume. For systems that sleep on reading the persistent clock, I'm open to having them fix it up as best they can later (partly why the code can handle read_persistent_clock() not returning anything), but unless I'm misreading this, it seems you're proposing to make systems that do have a safe persistent clock have to have the window where code may see the pre-suspend time after resume. Am I missing something here? thanks -john Maciej: Sorry for the dup, I forgot to reply to all on my first mail.
