lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM+2EuJsz9NgEskhYapxFg7UrimB3Po97DZGHtBCHTc8+vx_1g@mail.gmail.com>
Date:   Tue, 20 Sep 2022 01:09:37 +0530
From:   Jagath Jog J <jagathjog1996@...il.com>
To:     Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc:     a.zummo@...ertech.it, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, linux-rtc@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 2/2] rtc: maxim: Add Maxim max31329 real time clock

 Hi Alexandre,

Before sending v3 I have one comment,
Please see below.

On Mon, Sep 19, 2022 at 12:18 AM Alexandre Belloni
<alexandre.belloni@...tlin.com> wrote:
>
> On 17/09/2022 16:09:54+0530, Jagath Jog J wrote:
> > > This doesn't feel right, doesn't that break start-year?
> > >
> > > What is the actual time range supported by this RTC? Shouldn't you set
> > > the century?
> >
> > The time range supported by RTC is 2000 to 2199.
> > The alarm registers don't have a century bit.
> > I have tested the alarm for
> > 2122-09-17T01:22:00
> > 2142-09-17T01:22:00
> > 2160-02-29T00:00:00
> > 2196-02-29T00:00:00 etc
> >
> > I will add another condition such that if the century bit
> > from the time register is not set then configuring the
> > alarm for the next century is not allowed.
>
> The actual check should be for the alarm to not exceed 100 years in the
> future then. Else, this wouldn't work well with datetime offsetting.

Sure, I will add this check.

>
> > > > +static int max31329_set_time(struct device *dev, struct rtc_time *tm)
> > > > +{
> > > > +     struct max31329_data *max31329 = dev_get_drvdata(dev);
> > > > +     u8 regs[7];
> > > > +     int ret;
> > > > +
> > > > +     ret = max31329_get_osc_status(dev);
> > > > +     if (ret)
> > > > +             return ret;
> > > > +
> > >
> > > Checking the oscillator is not needed here but resetting the status is.
> >
> > Resetting the device will resets the digital block,
> > I2C-programmable registers and oscillator also,
> > The oscillator is taking some time around 80 milli sec
> > to be back as usual.
> >
> > Is it required to reset every time during the time setting?
> >
>
> Not but resetting the osc status is.

Actually, the STATUS register which contains the Oscillator Stop
Flag (OSF) bit is a read-only register. If the OSF bit is set, then
reading the status register will not clear the OSF bit.

Based on the oscillator disable and enable testing, I observed
that the OSF bit is getting cleared automatically once the clock
settles, which is taking around 80msec. The manual resetting
option is not there for the OSC status bit.

Can I set the time without resetting the OSC status?

Thank you,
Jagath

>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ