[PATCH 1/3] rtc: sh: stop resetting time to epoch

[PATCH 1/3] rtc: sh: stop resetting time to epoch

[Alexandre Belloni]

There is no point in resetting the time to epoch as this means that
userspace will never get the valuable information that time is actually
invalid.

Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
 drivers/rtc/rtc-sh.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-sh.c b/drivers/rtc/rtc-sh.c
index d417b203cbc5..f4ac9ec8fbb6 100644
--- a/drivers/rtc/rtc-sh.c
+++ b/drivers/rtc/rtc-sh.c
@@ -276,6 +276,9 @@ static int sh_rtc_read_time(struct device *dev, struct rtc_time *tm)
 	struct sh_rtc *rtc = dev_get_drvdata(dev);
 	unsigned int sec128, sec2, yr, yr100, cf_bit;
 
+	if (!(readb(rtc->regbase + RCR2) & RCR2_RTCEN))
+		return -EINVAL;
+
 	do {
 		unsigned int tmp;
 
@@ -600,12 +603,6 @@ static int __init sh_rtc_probe(struct platform_device *pdev)
 
 	rtc->rtc_dev->max_user_freq = 256;
 
-	/* reset rtc to epoch 0 if time is invalid */
-	if (rtc_read_time(rtc->rtc_dev, &r) < 0) {
-		rtc_time_to_tm(0, &r);
-		rtc_set_time(rtc->rtc_dev, &r);
-	}
-
 	device_init_wakeup(&pdev->dev, 1);
 	return 0;
 
-- 
2.20.1

[PATCH 2/3] rtc: sh: fix possible race condition

[Alexandre Belloni]

The IRQ is requested before the struct rtc is allocated and registered, but
this struct is used in the IRQ handler. This may lead to a NULL pointer
dereference.

Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc
struct before requesting the IRQ.

Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
 drivers/rtc/rtc-sh.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/rtc/rtc-sh.c b/drivers/rtc/rtc-sh.c
index f4ac9ec8fbb6..b582af10ddb5 100644
--- a/drivers/rtc/rtc-sh.c
+++ b/drivers/rtc/rtc-sh.c
@@ -531,6 +531,10 @@ static int __init sh_rtc_probe(struct platform_device *pdev)
 		rtc->clk = NULL;
 	}
 
+	rtc->rtc_dev = devm_rtc_allocate_device(&pdev->dev);
+	if (IS_ERR(rtc->rtc_dev))
+		return PTR_ERR(rtc->rtc_dev);
+
 	clk_enable(rtc->clk);
 
 	rtc->capabilities = RTC_DEF_CAPABILITIES;
@@ -594,15 +598,13 @@ static int __init sh_rtc_probe(struct platform_device *pdev)
 	sh_rtc_setaie(&pdev->dev, 0);
 	sh_rtc_setcie(&pdev->dev, 0);
 
-	rtc->rtc_dev = devm_rtc_device_register(&pdev->dev, "sh",
-					   &sh_rtc_ops, THIS_MODULE);
-	if (IS_ERR(rtc->rtc_dev)) {
-		ret = PTR_ERR(rtc->rtc_dev);
-		goto err_unmap;
-	}
-
+	rtc->rtc_dev->ops = &sh_rtc_ops;
 	rtc->rtc_dev->max_user_freq = 256;
 
+	ret = rtc_register_device(rtc->rtc_dev);
+	if (ret)
+		goto err_unmap;
+
 	device_init_wakeup(&pdev->dev, 1);
 	return 0;
 
-- 
2.20.1

Re: [PATCH 2/3] rtc: sh: fix possible race condition

[Geert Uytterhoeven]

On Wed, Mar 20, 2019 at 12:30 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> The IRQ is requested before the struct rtc is allocated and registered, but
> this struct is used in the IRQ handler. This may lead to a NULL pointer
> dereference.
>
> Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc
> struct before requesting the IRQ.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 3/3] rtc: sh: set range

[Alexandre Belloni]

The SH RTC is a BCD RTC with some version having 4 digits for the year.

The range for the RTCs with only 2 digits for the year was unfortunately
shifted to handle 1999 to 2098.

Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
 drivers/rtc/rtc-sh.c | 8 ++++++++
 include/linux/rtc.h  | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/rtc/rtc-sh.c b/drivers/rtc/rtc-sh.c
index b582af10ddb5..37964a867de7 100644
--- a/drivers/rtc/rtc-sh.c
+++ b/drivers/rtc/rtc-sh.c
@@ -601,6 +601,14 @@ static int __init sh_rtc_probe(struct platform_device *pdev)
 	rtc->rtc_dev->ops = &sh_rtc_ops;
 	rtc->rtc_dev->max_user_freq = 256;
 
+	if (rtc->capabilities & RTC_CAP_4_DIGIT_YEAR) {
+		rtc->rtc_dev->range_min = RTC_TIMESTAMP_BEGIN_1900;
+		rtc->rtc_dev->range_max = RTC_TIMESTAMP_END_9999;
+	} else {
+		rtc->rtc_dev->range_min = mktime64(1999, 1, 1, 0, 0, 0);
+		rtc->rtc_dev->range_max = mktime64(2098, 12, 31, 23, 59, 59);
+	}
+
 	ret = rtc_register_device(rtc->rtc_dev);
 	if (ret)
 		goto err_unmap;
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index f89bfbb54902..588120ba372c 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -165,6 +165,7 @@ struct rtc_device {
 #define RTC_TIMESTAMP_BEGIN_1900	-2208989361LL /* 1900-01-01 00:00:00 */
 #define RTC_TIMESTAMP_BEGIN_2000	946684800LL /* 2000-01-01 00:00:00 */
 #define RTC_TIMESTAMP_END_2099		4102444799LL /* 2099-12-31 23:59:59 */
+#define RTC_TIMESTAMP_END_9999		253402300799LL /* 9999-12-31 23:59:59 */
 
 extern struct rtc_device *devm_rtc_device_register(struct device *dev,
 					const char *name,
-- 
2.20.1

Re: [PATCH 3/3] rtc: sh: set range

[Geert Uytterhoeven]

On Wed, Mar 20, 2019 at 12:30 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> The SH RTC is a BCD RTC with some version having 4 digits for the year.
>
> The range for the RTCs with only 2 digits for the year was unfortunately
> shifted to handle 1999 to 2098.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

> --- a/include/linux/rtc.h
> +++ b/include/linux/rtc.h
> @@ -165,6 +165,7 @@ struct rtc_device {
>  #define RTC_TIMESTAMP_BEGIN_1900       -2208989361LL /* 1900-01-01 00:00:00 */

mktime64(1900, 1, 1, 0, 0, 0) = -2208988800 ??

Is this due to leap seconds, and mktime64() is valid for 1970 and later only?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 3/3] rtc: sh: set range

[Alexandre Belloni]

On 21/03/2019 11:22:26+0100, Geert Uytterhoeven wrote:
> On Wed, Mar 20, 2019 at 12:30 PM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> > The SH RTC is a BCD RTC with some version having 4 digits for the year.
> >
> > The range for the RTCs with only 2 digits for the year was unfortunately
> > shifted to handle 1999 to 2098.
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> 
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 
> > --- a/include/linux/rtc.h
> > +++ b/include/linux/rtc.h
> > @@ -165,6 +165,7 @@ struct rtc_device {
> >  #define RTC_TIMESTAMP_BEGIN_1900       -2208989361LL /* 1900-01-01 00:00:00 */
> 
> mktime64(1900, 1, 1, 0, 0, 0) = -2208988800 ??
> 
> Is this due to leap seconds, and mktime64() is valid for 1970 and later only?
> 

That's a bug, it seems I didn't use the correct timezone when doing the
calculation. Thanks for spotting that, you can send a patch to correct
it or I can do it.

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

Re: [PATCH 3/3] rtc: sh: set range

[Geert Uytterhoeven]

Hi Alexander,

On Fri, Mar 22, 2019 at 7:12 AM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 21/03/2019 11:22:26+0100, Geert Uytterhoeven wrote:
> > On Wed, Mar 20, 2019 at 12:30 PM Alexandre Belloni
> > <alexandre.belloni@bootlin.com> wrote:
> > > The SH RTC is a BCD RTC with some version having 4 digits for the year.
> > >
> > > The range for the RTCs with only 2 digits for the year was unfortunately
> > > shifted to handle 1999 to 2098.
> > >
> > > Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> >
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > > --- a/include/linux/rtc.h
> > > +++ b/include/linux/rtc.h
> > > @@ -165,6 +165,7 @@ struct rtc_device {
> > >  #define RTC_TIMESTAMP_BEGIN_1900       -2208989361LL /* 1900-01-01 00:00:00 */
> >
> > mktime64(1900, 1, 1, 0, 0, 0) = -2208988800 ??
> >
> > Is this due to leap seconds, and mktime64() is valid for 1970 and later only?
> >
>
> That's a bug, it seems I didn't use the correct timezone when doing the
> calculation. Thanks for spotting that, you can send a patch to correct
> it or I can do it.

Thanks for confirming, done.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/3] rtc: sh: stop resetting time to epoch

[Geert Uytterhoeven]

Hi Alexandre,

On Wed, Mar 20, 2019 at 12:30 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> There is no point in resetting the time to epoch as this means that
> userspace will never get the valuable information that time is actually
> invalid.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

Thanks for your patch!

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Impact before/after (cold boot):

    -sh-rtc fcff1000.rtc: setting system clock to 1970-01-01T00:00:00 UTC (0)
    +sh-rtc fcff1000.rtc: hctosys: unable to read the hardware clock

After warm boot (Linux reboot command):

    sh-rtc fcff1000.rtc: setting system clock to 2019-03-21T08:47:54
UTC (1553158074)

After reset (reset switch):

    sh-rtc fcff1000.rtc: hctosys: unable to read the hardware clock

Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds