From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Victor Ding <victording@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Alessandro Zummo <a.zummo@towertech.it>,
linux-rtc@vger.kernel.org
Subject: Re: [PATCH] rtc: cmos: initialize rtc time when reading alarm
Date: Fri, 14 Aug 2020 10:15:30 +0200 [thread overview]
Message-ID: <20200814081530.GA6530@piout.net> (raw)
In-Reply-To: <CANqTbdZhZL--JebFhZPkf2+VuCUs2b=Me-BoBHgAtt_MvQBX3A@mail.gmail.com>
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@bootlin.com> 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.
> >
> > > Signed-off-by: Victor Ding <victording@google.com>
> > > ---
> > >
> > > 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
next prev parent reply other threads:[~2020-08-14 8:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-13 5:41 [PATCH] rtc: cmos: initialize rtc time when reading alarm Victor Ding
2020-08-13 7:33 ` Alexandre Belloni
2020-08-14 6:10 ` Victor Ding
2020-08-14 8:15 ` Alexandre Belloni [this message]
2020-08-14 8:56 ` Victor Ding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200814081530.GA6530@piout.net \
--to=alexandre.belloni@bootlin.com \
--cc=a.zummo@towertech.it \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=victording@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.