Hi Alexandre, On Fri, Aug 14, 2020 at 6:15 PM Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> wrote: > > On 14/08/2020 16:10:13+1000, Victor Ding wrote: > > Hi Alexandre, > > > > On Thu, Aug 13, 2020 at 5:33 PM Alexandre Belloni > > <alexandre.belloni@xxxxxxxxxxx> wrote: > > > > > > Hi, > > > > > > On 13/08/2020 15:41:34+1000, Victor Ding wrote: > > > > cmos_read_alarm() may leave certain fields of a struct rtc_time > > > > untouched; therefore, these fields contain garbage if not properly > > > > initialized, leading to inconsistent values when converting into > > > > time64_t. > > > > This patch to set all fields of a struct rtc_time to -1 before calling > > > > cmos_read_alarm(). > > > > > > > > > > I don't think this actually helps with the conversion as mktime64 > > > is taking unsigned int so I would think you need the whole logic that is > > > in __rtc_read_alarm > > > > It's true that this change does not produce a correct time64_t; however, > > it isn't the intention either. The proposed change only produces a > > consistent value: calling obtaining identical struct rtc_time if the CMOS > > wakealarm is unchanged. In the case of suspend/resume, a correct value > > time64_t is not necessary; a consistent value is sufficient to correctly > > perform an equality test for `t_current_expires` and `t_saved_expires`. > > Logic to deduce a correct time64_t is expensive and hence I would like to > > avoid __rtc_read_alarm's logic here. > > > > Prior to this patch, the struct rtc_time is uninitialized. After calling > > cmos_read_alarm(), the tm_year field is always left untouched and hence > > contains only garbage. On platforms without enhanced RTC timers, the > > tm_mon and tm_mday fields are left with garbage as well. Therefore, > > `t_current_expires` and `t_saved_expires` from garbage data, which leads > > to incorrect equality test results. > > > > Seeing that saved_wkalrm is initialized to zero, wouldn't it be > sufficient to initialize current_alarm to 0? This can be done simply at > the declaration. I personally find the -1 to be confusing especially > since the result ends up being architecture dependent. > Good point. Initializing the struct to 0 is also sufficient; I'll update the patch to initialize the fields to 0 and submit the updated version. Note that both `saved_wkalrm` and `current_alarm` must be initialized. `cmos_suspend` may be called multiple times; `cmos_read_alarm` may or may not update `time.tm_mon` or `time.tm_mday` depends on `cmos->day_alrm` and `cmos->mon_alrm`. Both `day_alrm` and `mon_alrm` could theoretically change. Say if at first `day_alrm` is enabled, `cmos_read_alarm` would fill `time.tm_mday`. Later on, if `day_alrm` becomes disabled, `cmos_read_alarm` would not update `time.tm_mday` and hence leaves its value as garbage. > > > > > > > Signed-off-by: Victor Ding <victording@xxxxxxxxxx> > > > > --- > > > > > > > > drivers/rtc/rtc-cmos.c | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c > > > > index bcc96ab7793f..c99af567780d 100644 > > > > --- a/drivers/rtc/rtc-cmos.c > > > > +++ b/drivers/rtc/rtc-cmos.c > > > > @@ -1006,6 +1006,7 @@ static int cmos_suspend(struct device *dev) > > > > enable_irq_wake(cmos->irq); > > > > } > > > > > > > > + memset(&cmos->saved_wkalrm.time, -1, sizeof(struct rtc_time)); > > > > cmos_read_alarm(dev, &cmos->saved_wkalrm); > > > > > > > > dev_dbg(dev, "suspend%s, ctrl %02x\n", > > > > @@ -1054,6 +1055,7 @@ static void cmos_check_wkalrm(struct device *dev) > > > > return; > > > > } > > > > > > > > + memset(¤t_alarm.time, -1, sizeof(struct rtc_time)); > > > > cmos_read_alarm(dev, ¤t_alarm); > > > > t_current_expires = rtc_tm_to_time64(¤t_alarm.time); > > > > t_saved_expires = rtc_tm_to_time64(&cmos->saved_wkalrm.time); > > > > -- > > > > 2.28.0.236.gb10cc79966-goog > > > > > > > > > > -- > > > Alexandre Belloni, Bootlin > > > Embedded Linux and Kernel engineering > > > https://bootlin.com > > > > Best regards, > > Victor Ding > > -- > Alexandre Belloni, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Best regards, Victor Ding
