linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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(&current_alarm.time, -1, sizeof(struct rtc_time));
> > >       cmos_read_alarm(dev, &current_alarm);
> > >       t_current_expires = rtc_tm_to_time64(&current_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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).