mbox series

[v2,0/2] rtc: Add ASPEED RTC driver

Message ID 20190325133159.10653-1-joel@jms.id.au
Headers show
Series rtc: Add ASPEED RTC driver | expand

Message

Joel Stanley March 25, 2019, 1:31 p.m. UTC 
I finally found some time to send a v2 for this one. Thanks Alexandre
for the review back in October.

v2: Address review from Alexandre

Joel Stanley (2):
  dt-bindings: rtc: Add on-chip ASPEED RTC documentation
  rtc: Add ASPEED RTC driver

 .../devicetree/bindings/rtc/rtc-aspeed.txt    |  19 +++
 drivers/rtc/Kconfig                           |  10 ++
 drivers/rtc/Makefile                          |   1 +
 drivers/rtc/rtc-aspeed.c                      | 152 ++++++++++++++++++
 4 files changed, 182 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-aspeed.txt
 create mode 100644 drivers/rtc/rtc-aspeed.c

Comments

Alexandre Belloni March 25, 2019, 2:59 p.m. UTC | #1 
Hi,

This seems mostly good to me.

On 26/03/2019 00:01:59+1030, Joel Stanley wrote:
> +	dev_dbg(dev, "%s: %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
> +			1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
> +			tm->tm_hour, tm->tm_min, tm->tm_sec);
> +

We now have %ptR, could you use that?

> +	rtc->rtc_dev->ops = &aspeed_rtc_ops;
> +	rtc->rtc_dev->range_min = RTC_TIMESTAMP_BEGIN_1900;
> +	rtc->rtc_dev->range_max = 38814989399LL; /* 3199-12-31 23:59:59 */
> +

I'm curious how many RTC have been properly designed, could you run
rtc-range?

https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/rtc-tools.git/tree/rtc-range.c

Thanks!
Joel Stanley March 25, 2019, 3:28 p.m. UTC | #2 
On Mon, 25 Mar 2019 at 14:59, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> Hi,
>
> This seems mostly good to me.
>
> On 26/03/2019 00:01:59+1030, Joel Stanley wrote:
> > +     dev_dbg(dev, "%s: %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
> > +                     1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
> > +                     tm->tm_hour, tm->tm_min, tm->tm_sec);
> > +
>
> We now have %ptR, could you use that?

I tried this:

  dev_dbg(dev, "%s: %ptR", __func__, tm);

Yes, that appears to do the job. Can you make the change when applying?

>
> > +     rtc->rtc_dev->ops = &aspeed_rtc_ops;
> > +     rtc->rtc_dev->range_min = RTC_TIMESTAMP_BEGIN_1900;
> > +     rtc->rtc_dev->range_max = 38814989399LL; /* 3199-12-31 23:59:59 */
> > +
>
> I'm curious how many RTC have been properly designed, could you run
> rtc-range?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/rtc-tools.git/tree/rtc-range.c

It appears to pass the test:

Testing 2000-02-28 23:59:59.
OK

Testing 2038-01-19 03:14:07.
OK

Testing 2069-12-31 23:59:59.
OK

Testing 2099-12-31 23:59:59.
OK

Testing 2100-02-28 23:59:59.
OK

Testing 2106-02-07 06:28:15.
OK

Testing 2262-04-11 23:47:16.
OK

The qemu model I have for the device failed though. A good test! Are
you going to put it in the kernel tree?

Cheers,

Joel
Alexandre Belloni March 25, 2019, 3:43 p.m. UTC | #3 
On 25/03/2019 15:28:26+0000, Joel Stanley wrote:
> On Mon, 25 Mar 2019 at 14:59, Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> > On 26/03/2019 00:01:59+1030, Joel Stanley wrote:
> > > +     dev_dbg(dev, "%s: %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
> > > +                     1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
> > > +                     tm->tm_hour, tm->tm_min, tm->tm_sec);
> > > +
> >
> > We now have %ptR, could you use that?
> 
> I tried this:
> 
>   dev_dbg(dev, "%s: %ptR", __func__, tm);
> 
> Yes, that appears to do the job. Can you make the change when applying?
> 

Ok, I'll do that.

> >
> > > +     rtc->rtc_dev->ops = &aspeed_rtc_ops;
> > > +     rtc->rtc_dev->range_min = RTC_TIMESTAMP_BEGIN_1900;
> > > +     rtc->rtc_dev->range_max = 38814989399LL; /* 3199-12-31 23:59:59 */
> > > +
> >
> > I'm curious how many RTC have been properly designed, could you run
> > rtc-range?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/rtc-tools.git/tree/rtc-range.c
> 
> It appears to pass the test:
> 
> Testing 2000-02-28 23:59:59.
> OK
> 
> Testing 2038-01-19 03:14:07.
> OK
> 
> Testing 2069-12-31 23:59:59.
> OK
> 
> Testing 2099-12-31 23:59:59.
> OK
> 
> Testing 2100-02-28 23:59:59.
> OK
> 
> Testing 2106-02-07 06:28:15.
> OK
> 
> Testing 2262-04-11 23:47:16.
> OK
> 
> The qemu model I have for the device failed though. A good test! Are
> you going to put it in the kernel tree?
> 

I was planning to add more dates to test and detect when the range is
properly reported by the rtc (right now, it reports a failure) before
doing so.
Alexandre Belloni March 25, 2019, 4:10 p.m. UTC | #4 
On 25/03/2019 15:28:26+0000, Joel Stanley wrote:
> On Mon, 25 Mar 2019 at 14:59, Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> >
> > Hi,
> >
> > This seems mostly good to me.
> >
> > On 26/03/2019 00:01:59+1030, Joel Stanley wrote:
> > > +     dev_dbg(dev, "%s: %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
> > > +                     1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
> > > +                     tm->tm_hour, tm->tm_min, tm->tm_sec);
> > > +
> >
> > We now have %ptR, could you use that?
> 
> I tried this:
> 
>   dev_dbg(dev, "%s: %ptR", __func__, tm);
> 
> Yes, that appears to do the job. Can you make the change when applying?
> 

While doing that change, I relaized that the whole locking is probably
unnecessary as all the rtc_ops are called with the rtc lock taken. If
you are not planning to add alarm support, the lock can be removed.
Joel Stanley March 27, 2019, 1 a.m. UTC | #5 
On Mon, 25 Mar 2019 at 16:10, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:> >
> While doing that change, I relaized that the whole locking is probably
> unnecessary as all the rtc_ops are called with the rtc lock taken. If
> you are not planning to add alarm support, the lock can be removed.

I had a stab at alarm support, but the select() tests in rtctest.c
were failing. I will submit a v3 without the locking so we can get
that out of the way, and defer adding alarm support for now.

Cheers,

Joel