From: Finn Thain <fthain@linux-m68k.org>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Daniel Palmer <daniel@0x0f.com>,
Michael Pavone <pavone@retrodev.com>,
linux-m68k@lists.linux-m68k.org, linux-rtc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit
Date: Sat, 5 Oct 2024 14:23:28 +1000 (AEST) [thread overview]
Message-ID: <10bb949d-07f5-5cea-b658-8969b5bda6ae@linux-m68k.org> (raw)
In-Reply-To: <20241003081015363ed024@mail.local>
On Thu, 3 Oct 2024, Alexandre Belloni wrote:
>
> ... while you are it, can you use m48t59->rtc->start_secs and
> m48t59->rtc->set_start_time in probe instead of offsetting tm_year in
> read_time/set_time so we can later use device tree or any other
> mechanism to extend the range?
>
That didn't work out as I'd hoped. I booted a patched kernel (diff below)
under qemu-system-sparc64:
~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do
date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
Thu Jan 1 01:01:00 UTC 1970
Thu Jan 1 01:01:00 1970 0.000000 seconds
Fri Jan 1 01:01:00 UTC 1971
Tue Nov 24 18:32:44 1998 0.000000 seconds
Fri Jan 1 01:01:00 UTC 1999
Tue Nov 24 18:32:44 2026 0.000000 seconds
Sat Jan 1 01:01:00 UTC 2000
Sun Jan 2 23:29:16 2000 0.000000 seconds
Mon Jan 1 01:01:00 UTC 2024
Tue Jan 2 23:29:16 2024 0.000000 seconds
Wed Jan 1 01:01:00 UTC 2025
Thu Jan 2 23:29:16 2025 0.000000 seconds
Sun Jan 1 01:01:00 UTC 2068
hwclock: RTC_SET_TIME: Numerical result out of range
Tue Jan 1 01:01:00 UTC 2069
hwclock: RTC_SET_TIME: Numerical result out of range
~ #
Here's the result from an unpatched kernel (v6.11):
~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do
date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
Thu Jan 1 01:01:00 UTC 1970
Thu Jan 1 01:01:00 1970 0.000000 seconds
Fri Jan 1 01:01:00 UTC 1971
Fri Jan 1 01:01:00 1971 0.000000 seconds
Fri Jan 1 01:01:00 UTC 1999
Fri Jan 1 01:01:01 1999 0.000000 seconds
Sat Jan 1 01:01:00 UTC 2000
Sat Jan 1 01:01:00 2000 0.000000 seconds
Mon Jan 1 01:01:00 UTC 2024
Mon Jan 1 01:01:00 2024 0.000000 seconds
Wed Jan 1 01:01:00 UTC 2025
Wed Jan 1 01:01:00 2025 0.000000 seconds
Sun Jan 1 01:01:00 UTC 2068
hwclock: RTC_RD_TIME: Invalid argument
Tue Jan 1 01:01:00 UTC 2069
hwclock: RTC_RD_TIME: Invalid argument
~ #
I'm afraid I don't see how we might avoid adding/subtracting in
read_time/set_time given that we must avoid messing up the present date
when users boot into an upgraded kernel.
diff --git a/arch/sparc/kernel/time_32.c b/arch/sparc/kernel/time_32.c
index 08bbdc458596..41ae3d1aa12e 100644
--- a/arch/sparc/kernel/time_32.c
+++ b/arch/sparc/kernel/time_32.c
@@ -255,6 +255,7 @@ static void mostek_write_byte(struct device *dev, u32 ofs, u8 val)
static struct m48t59_plat_data m48t59_data = {
.read_byte = mostek_read_byte,
.write_byte = mostek_write_byte,
+ .start_year = 1968,
};
/* resource is set at runtime */
diff --git a/arch/sparc/kernel/time_64.c b/arch/sparc/kernel/time_64.c
index 60f1c8cc5363..eceb3fadb71a 100644
--- a/arch/sparc/kernel/time_64.c
+++ b/arch/sparc/kernel/time_64.c
@@ -544,6 +544,7 @@ static void mostek_write_byte(struct device *dev, u32 ofs, u8 val)
static struct m48t59_plat_data m48t59_data = {
.read_byte = mostek_read_byte,
.write_byte = mostek_write_byte,
+ .start_year = 1968,
};
static struct platform_device m48t59_rtc = {
diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
index f0f6b9b6daec..d7e1f79cd52b 100644
--- a/drivers/rtc/rtc-m48t59.c
+++ b/drivers/rtc/rtc-m48t59.c
@@ -82,10 +82,6 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
dev_dbg(dev, "Century bit is enabled\n");
tm->tm_year += 100; /* one century */
}
-#ifdef CONFIG_SPARC
- /* Sun SPARC machines count years since 1968 */
- tm->tm_year += 68;
-#endif
tm->tm_wday = bcd2bin(val & 0x07);
tm->tm_hour = bcd2bin(M48T59_READ(M48T59_HOUR) & 0x3F);
@@ -108,11 +104,6 @@ static int m48t59_rtc_set_time(struct device *dev, struct rtc_time *tm)
u8 val = 0;
int year = tm->tm_year;
-#ifdef CONFIG_SPARC
- /* Sun SPARC machines count years since 1968 */
- year -= 68;
-#endif
-
dev_dbg(dev, "RTC set time %04d-%02d-%02d %02d/%02d/%02d\n",
year + 1900, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
@@ -163,10 +154,7 @@ static int m48t59_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
M48T59_SET_BITS(M48T59_CNTL_READ, M48T59_CNTL);
tm->tm_year = bcd2bin(M48T59_READ(M48T59_YEAR));
-#ifdef CONFIG_SPARC
- /* Sun SPARC machines count years since 1968 */
- tm->tm_year += 68;
-#endif
+
/* tm_mon is 0-11 */
tm->tm_mon = bcd2bin(M48T59_READ(M48T59_MONTH)) - 1;
@@ -199,11 +187,6 @@ static int m48t59_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
unsigned long flags;
int year = tm->tm_year;
-#ifdef CONFIG_SPARC
- /* Sun SPARC machines count years since 1968 */
- year -= 68;
-#endif
-
/* If no irq, we don't support ALARM */
if (m48t59->irq == NO_IRQ)
return -EIO;
@@ -458,6 +441,10 @@ static int m48t59_rtc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, m48t59);
m48t59->rtc->ops = &m48t59_rtc_ops;
+ m48t59->rtc->range_min = mktime64(1900, 1, 1, 0, 0, 0);
+ m48t59->rtc->range_max = mktime64(1999, 12, 31, 23, 59, 59);
+ m48t59->rtc->start_secs = mktime64(pdata->start_year, 1, 1, 0, 0, 0);
+ m48t59->rtc->set_start_time = true;
nvmem_cfg.size = pdata->offset;
ret = devm_rtc_nvmem_register(m48t59->rtc, &nvmem_cfg);
diff --git a/include/linux/rtc/m48t59.h b/include/linux/rtc/m48t59.h
index 9465d5405fe2..b01c514d7079 100644
--- a/include/linux/rtc/m48t59.h
+++ b/include/linux/rtc/m48t59.h
@@ -56,6 +56,9 @@ struct m48t59_plat_data {
void __iomem *ioaddr;
/* offset to RTC registers, automatically set according to the type */
unsigned int offset;
+
+ /* value to be used to initialize rtc->start_secs */
+ time64_t start_year;
};
#endif /* _LINUX_RTC_M48T59_H_ */
next prev parent reply other threads:[~2024-10-05 4:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-03 3:23 [PATCH 0/2] Finn Thain
2024-10-03 3:23 ` [PATCH 2/2] m68k: mvme147, mvme16x: Adopt rtc-m48t59 platform driver Finn Thain
2024-10-03 3:23 ` [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit Finn Thain
2024-10-03 7:46 ` Geert Uytterhoeven
2024-10-03 22:20 ` Finn Thain
2024-10-03 8:10 ` Alexandre Belloni
2024-10-03 22:31 ` Finn Thain
2024-10-05 4:23 ` Finn Thain [this message]
2024-10-20 20:18 ` 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=10bb949d-07f5-5cea-b658-8969b5bda6ae@linux-m68k.org \
--to=fthain@linux-m68k.org \
--cc=alexandre.belloni@bootlin.com \
--cc=daniel@0x0f.com \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-rtc@vger.kernel.org \
--cc=pavone@retrodev.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
all inboxes | Powered by JetHome®