Messages in this thread Patch in this message | | | Date | Fri, 27 Mar 2015 14:22:22 +0100 | From | Alexandre Belloni <> | Subject | Re: RTC: Restore alarm after resume |
| |
Hi Matthew,
On 22/12/2014 at 19:19:39 +0000, Matthew Garrett wrote : > Some platform firmware may interfere with the RTC alarm over suspend, > resulting in the kernel and hardware having different ideas about system state > but also potentially causing problems with firmware that assumes the OS will > clean this case up. This patch saves the RTC alarm state on suspend and will > restore it on resume if the alarm has not yet fired - if it has, it will clear > the RTC alarm. > > Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> > Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> > --- > drivers/rtc/class.c | 24 ++++++++++++++++++++++++ > include/linux/rtc.h | 4 ++++ > 2 files changed, 28 insertions(+) > > diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c > index 472a5ad..c7e09e2 100644 > --- a/drivers/rtc/class.c > +++ b/drivers/rtc/class.c > @@ -55,6 +55,8 @@ static int rtc_suspend(struct device *dev) > struct timespec64 delta, delta_delta; > int err; > > + rtc->valid_alarm = !rtc_read_alarm(rtc, &rtc->alarm); > + > if (has_persistent_clock()) > return 0; > > @@ -102,6 +104,27 @@ static int rtc_resume(struct device *dev) > struct timespec64 sleep_time; > int err; > > + /* > + * Ensure that the platform hasn't overwritten a pending alarm while > + * suspended > + */ > + if (rtc->valid_alarm) { > + long now, scheduled; > + > + rtc_read_time(rtc, &tm); > + rtc_tm_to_time(&rtc->alarm.time, &scheduled); > + rtc_tm_to_time(&tm, &now); > + > + /* Clear the alarm registers if it went off during suspend */ > + if (scheduled <= now) { > + rtc_time_to_tm(0, &rtc->alarm.time); > + rtc->alarm.enabled = 0; > + } > + > + if (rtc->ops && rtc->ops->set_alarm) > + rtc->ops->set_alarm(rtc->dev.parent, &rtc->alarm); > + } > +
My main concern here is that reading the time and the alarm can be slow, in particular with i2c RTC.
Isn't that issue pretty much specific to x86? I know you think otherwise but I believe this would better be done from your driver. If more platforms/RTCs are affected, it will still be time to try to solve it in a more generic way.
Moreover, the class suspend/resume functions are only defined when CONFIG_RTC_HCTOSYS is set so you may still have broken platforms with some configurations.
-- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
| |