mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sam Protsenko <semen.protsenko@linaro.org>
To: Alessandro Zummo <a.zummo@towertech.it>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc: linux-rtc@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH v2 3/3] rtc: s3c: Add time range
Date: Thu, 21 Oct 2021 23:22:56 +0300	[thread overview]
Message-ID: <20211021202256.28517-4-semen.protsenko@linaro.org> (raw)
In-Reply-To: <20211021202256.28517-1-semen.protsenko@linaro.org>

This RTC driver starts counting from 2000 to avoid Y2K problem. Also it
only supports 100 years range for all RTCs.  Provide that info to RTC
framework. Also remove check for 100 years range in s3c_rtc_settime(),
as RTC core won't pass any invalid values to the driver, now that
correct range is set.

Here is the rationale on 100 years range limitation. Info on different
Samsung RTCs (credit goes to Krzysztof Kozlowski):
  - All S3C chips have only 8-bit wide year register (can store 100
    years range in BCD format)
  - S5Pv210 and Exynos chips have 12-bit year register (can store 1000
    years range in BCD format)

But in reality we usually can't make use of those 12 bits either:
  - RTCs might think that both 2000 and 2100 years are leap years. So
    when the YEAR register is 0, RTC goes from 28 Feb to 29 Feb, and
    when the YEAR register is 100, RTC also goes from 28 Feb to 29 Feb.
    This is of course incorrect: RTC breaks leap year criteria, which
    breaks the time contiguity, which leads to inability to use the RTC
    after year of 2099. It was found for example on Exynos850 SoC.
  - Despite having 12 bits for holding the year value, RTC might
    overflow the year value internally much earlier. For example, on
    Exynos850 the RTC overflows when YEAR=159, making the next YEAR=0.
    This way RTC actually has range of 160 years, not 1000 as one may
    think.

All that said, there is no sense in trying to increase the time range
for more than 100 years on RTCs that seem capable of that. It also
doesn't have too much practical value -- current hardware will be
probably obsolete by 2100.

Tested manually on Exynos850 RTC:

    $ date -s "1999-12-31 23:59:50"
    $ hwclock -w -f /dev/rtc0
    $ date -s "2100-01-01 00:00:00"
    $ hwclock -w -f /dev/rtc0
    $ date -s "2000-01-01 00:00:00"
    $ hwclock -w -f /dev/rtc0
    $ hwclock -r -f /dev/rtc0
    $ date -s "2099-12-31 23:59:50"
    $ hwclock -w -f /dev/rtc0
    $ hwclock -r -f /dev/rtc0

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
---
Changes in v2:
  - Removed check for 100 years range in s3c_rtc_settime()
  - Improved the commit message

 drivers/rtc/rtc-s3c.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index d1baf655c008..db529733c9c4 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -219,11 +219,6 @@ static int s3c_rtc_settime(struct device *dev, struct rtc_time *tm)
 	rtc_tm.tm_year -= 100;
 	rtc_tm.tm_mon += 1;
 
-	if (rtc_tm.tm_year < 0 || rtc_tm.tm_year >= 100) {
-		dev_err(dev, "rtc only supports 100 years\n");
-		return -EINVAL;
-	}
-
 	return s3c_rtc_write_time(info, &rtc_tm);
 }
 
@@ -478,6 +473,8 @@ static int s3c_rtc_probe(struct platform_device *pdev)
 	}
 
 	info->rtc->ops = &s3c_rtcops;
+	info->rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
+	info->rtc->range_max = RTC_TIMESTAMP_END_2099;
 
 	ret = devm_rtc_register_device(info->rtc);
 	if (ret)
-- 
2.30.2


  parent reply	other threads:[~2021-10-21 20:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-21 20:22 [PATCH v2 0/3] rtc: s3c: S3C driver improvements Sam Protsenko
2021-10-21 20:22 ` [PATCH v2 1/3] rtc: s3c: Remove usage of devm_rtc_device_register() Sam Protsenko
2021-10-21 20:22 ` [PATCH v2 2/3] rtc: s3c: Extract read/write IO into separate functions Sam Protsenko
2021-10-21 20:22 ` Sam Protsenko [this message]
2021-10-22  8:54   ` [PATCH v2 3/3] rtc: s3c: Add time range Krzysztof Kozlowski
2021-10-23 21:58 ` [PATCH v2 0/3] rtc: s3c: S3C driver improvements Alexandre Belloni
2021-11-11 17:05   ` Sam Protsenko
2021-11-12 22:19     ` Alexandre Belloni

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=20211021202256.28517-4-semen.protsenko@linaro.org \
    --to=semen.protsenko@linaro.org \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®