[PATCH 0/2]
Subsystems (4)
cover [PATCH 0/2]
This series removes some duplicate RTC driver code. rtc-m48t59 is tweaked to bring it into equivalence with the RTC drivers in arch/m68k/mvme*. Then the latter drivers are removed and platform devices added to make use of the former.
The second patch depends upon the first, which will require some coordination between the maintainers of the RTC and m68k subsystems.
Finn Thain (2):
rtc: m48t59: Accommodate chips that lack a century bit
m68k: mvme147, mvme16x: Adopt rtc-m48t59 platform driver
arch/m68k/configs/multi_defconfig | 1 + arch/m68k/configs/mvme147_defconfig | 1 + arch/m68k/configs/mvme16x_defconfig | 1 + arch/m68k/include/asm/mvme147hw.h | 19 +--- arch/m68k/include/asm/mvme16xhw.h | 18 +-- arch/m68k/mvme147/config.c | 54 ++++----- arch/m68k/mvme16x/Makefile | 2 +- arch/m68k/mvme16x/config.c | 56 ++++------ arch/m68k/mvme16x/rtc.c | 165 ---------------------------- drivers/rtc/rtc-m48t59.c | 31 +++--- 10 files changed, 67 insertions(+), 281 deletions(-) delete mode 100644 arch/m68k/mvme16x/rtc.c
Signature · 1 line
2.39.5
PATCH 1/2 rtc: m48t59: Accommodate chips that lack a century bit
The m48t59 driver is needed by both SPARC and MVME systems. Linux on MVME uses 1970 as "year zero" rather than 1968 that's used on SPARC. Add support for the MVME convention. Otherwise, the RTC on non-SPARC systems can only read and write dates between 1900 and 1999.
--- drivers/rtc/rtc-m48t59.c | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-)
drivers/rtc/rtc-m48t59.c +15 -16
@@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)return readb (m48t59->ioaddr+ofs); } +/* +* Sun SPARC machines count years since 1968. MVME machines running Linux +* count years since 1970. +*/ + +#ifdef CONFIG_SPARC +#define YEAR0 68 +#else +#define YEAR0 70 +#endif +/* * NOTE: M48T59 only uses BCD mode */
@@ -82,10 +93,7 @@ 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_year +=YEAR0 ; tm->tm_wday =bcd2bin (val &0x07 ); tm->tm_hour =bcd2bin (M48T59_READ (M48T59_HOUR ) &0x3F );
@@ -108,10 +116,7 @@ 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 + year -=YEAR0 ; dev_dbg(dev, "RTC set time %04d-%02d-%02d %02d/%02d/%02d\n", year + 1900, tm->tm_mon, tm->tm_mday,
@@ -163,10 +168,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->tm_year +=YEAR0 ;/* tm_mon is 0-11 */ tm->tm_mon =bcd2bin (M48T59_READ (M48T59_MONTH )) -1 ;
@@ -199,10 +201,7 @@ 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 + year -=YEAR0 ;/* If no irq, we don't support ALARM */ if (m48t59->irq ==NO_IRQ )
Signature · 1 line
2.39.5
Geert Uytterhoeven
maintainerRe: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit
Hi Finn,
Quoted 7 lines · Finn Thain
The m48t59 driver is needed by both SPARC and MVME systems. Linux on MVME uses 1970 as "year zero" rather than 1968 that's used on SPARC. Add support for the MVME convention. Otherwise, the RTC on non-SPARC systems can only read and write dates between 1900 and 1999.
Tested-by Daniel Palmer <[email protected]>Signed-off-by Finn Thain <[email protected]>
Thanks for your patch!
Quoted 4 lines
drivers/rtc/rtc-m48t59.c +0
-0@@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)return readb (m48t59->ioaddr+ofs);
drivers/rtc/rtc-m48t59.c m48t59_mem_readb(struct device *dev, u32 ofs) · line 67
Quoted 10 lines
drivers/rtc/rtc-m48t59.c +8
-0} +/* +* Sun SPARC machines count years since 1968. MVME machines running Linux +* count years since 1970. +*/ + +#ifdef CONFIG_SPARC +#define YEAR0 68 +#else
+#define YEAR0 70
drivers/rtc/rtc-m48t59.c m48t59_mem_readb(struct device *dev, u32 ofs) · line 69
Quoted 1 line
drivers/rtc/rtc-m48t59.c +1
-0+#endif
This causes a change in behavior on other non-SPARC platforms, if any out-of-tree platform exists that uses this driver.
So I'd rather use:
#elif defined(CONFIG_VME)
#define YEAR0 70
#else
#define YEAR0 0
#endifdrivers/rtc/rtc-m48t59.c static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm) · line 96
Quoted 13 lines
drivers/rtc/rtc-m48t59.c +2
-4+/* * NOTE: M48T59 only uses BCD mode */ @@ -82,10 +93,7 @@ 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_year +=YEAR0 ;
Upon closer look, the driver uses platform data, so a better solution would be to add the year0 offset to struct m48t59_plat_data.
Another suggestion for improvement, not related to this patch, would be to differentiate among M48T59, M48T02, and M48T08 by using platform_driver.id_table and platform_device_id.driver_data, instead of m48t59_plat_data.type.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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/2] rtc: m48t59: Accommodate chips that lack a century bit
Quoted 2 lines · Geert Uytterhoeven
Thanks for your patch!
Thanks for your review.
Quoted 15 lines
Quoted 4 lines
drivers/rtc/rtc-m48t59.c +0
-0@@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)return readb (m48t59->ioaddr+ofs);drivers/rtc/rtc-m48t59.c m48t59_mem_readb(struct device *dev, u32 ofs) · line 67
Quoted 10 lines
drivers/rtc/rtc-m48t59.c +8
-0} +/* +* Sun SPARC machines count years since 1968. MVME machines running Linux +* count years since 1970. +*/ + +#ifdef CONFIG_SPARC +#define YEAR0 68 +#else +#define YEAR0 70
Quoted 5 lines
drivers/rtc/rtc-m48t59.c m48t59_mem_readb(struct device *dev, u32 ofs) · line 69
Quoted 1 line
drivers/rtc/rtc-m48t59.c +1
-0+#endif This causes a change in behavior on other non-SPARC platforms, if any out-of-tree platform exists that uses this driver.
I'm unaware of any need to support out-of-tree code. Do you see think such a requirement would be feasible somehow? Is this documented somewhere?
Quoted 8 lines
So I'd rather use:
#elif defined(CONFIG_VME) #define YEAR0 70 #else #define YEAR0 0 #endif
That is a Y2K bug, right?
Quoted 8 lines
Quoted 8 lines
drivers/rtc/rtc-m48t59.c +1
-0+/* * NOTE: M48T59 only uses BCD mode */ @@ -82,10 +93,7 @@ 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 */ }
Quoted 9 lines
drivers/rtc/rtc-m48t59.c static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm) · line 96
Quoted 5 lines
drivers/rtc/rtc-m48t59.c +1
-4-#ifdef CONFIG_SPARC -/* Sun SPARC machines count years since 1968 */ - tm->tm_year +=68 ; -#endif + tm->tm_year +=YEAR0 ;Upon closer look, the driver uses platform data, so a better solution would be to add the year0 offset to struct
m48t59_plat_data.
I agree.
Quoted 5 lines
Another suggestion for improvement, not related to this patch, would be to differentiate among M48T59, M48T02, and M48T08 by using platform_driver.id_table and platform_device_id.driver_data, instead of m48t59_plat_data.type.
Yes, that's well out-of-scope I think.
Alexandre Belloni
maintainerRe: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit
In reply to Finn ThainHello,
Quoted 34 lines · Finn Thain
The m48t59 driver is needed by both SPARC and MVME systems. Linux on MVME uses 1970 as "year zero" rather than 1968 that's used on SPARC. Add support for the MVME convention. Otherwise, the RTC on non-SPARC systems can only read and write dates between 1900 and 1999.
Tested-by Daniel Palmer <[email protected]>Signed-off-by Finn Thain <[email protected]>--- drivers/rtc/rtc-m48t59.c | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-)drivers/rtc/rtc-m48t59.c +11
-0@@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)return readb (m48t59->ioaddr+ofs); } +/* +* Sun SPARC machines count years since 1968. MVME machines running Linux +* count years since 1970. +*/ + +#ifdef CONFIG_SPARC +#define YEAR0 68 +#else +#define YEAR0 70 +#endif +/* * NOTE: M48T59 only uses BCD mode */
drivers/rtc/rtc-m48t59.c static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm) · line 97
Quoted 9 lines
drivers/rtc/rtc-m48t59.c +1
-4@@ -82,10 +93,7 @@ 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_year +=YEAR0 ;
I'm super happy to see someone working on this, 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?
It is super funny because I was telling Geert that I wanted to get rid of this #ifdef CONFIG_SPARC two weeks ago at LPC. That could indeed then come from platform data.
Quoted 41 lines
drivers/rtc/rtc-m48t59.c +3
-12tm->tm_wday =bcd2bin (val &0x07 ); tm->tm_hour =bcd2bin (M48T59_READ (M48T59_HOUR ) &0x3F );@@ -108,10 +116,7 @@ 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 + year -=YEAR0 ; dev_dbg(dev, "RTC set time %04d-%02d-%02d %02d/%02d/%02d\n", year + 1900, tm->tm_mon, tm->tm_mday,@@ -163,10 +168,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->tm_year +=YEAR0 ;/* tm_mon is 0-11 */ tm->tm_mon =bcd2bin (M48T59_READ (M48T59_MONTH )) -1 ;@@ -199,10 +201,7 @@ 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 + year -=YEAR0 ;/* If no irq, we don't support ALARM */ if (m48t59->irq ==NO_IRQ )Signature · 1 line
2.39.5
Signature · 3 lines
Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit
Quoted 41 lines · Alexandre Belloni
Quoted 40 lines · Finn Thain
The m48t59 driver is needed by both SPARC and MVME systems. Linux on MVME uses 1970 as "year zero" rather than 1968 that's used on SPARC. Add support for the MVME convention. Otherwise, the RTC on non-SPARC systems can only read and write dates between 1900 and 1999.
Tested-by Daniel Palmer <[email protected]>Signed-off-by Finn Thain <[email protected]>--- drivers/rtc/rtc-m48t59.c | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-)drivers/rtc/rtc-m48t59.c +11
-3@@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)return readb (m48t59->ioaddr+ofs); } +/* +* Sun SPARC machines count years since 1968. MVME machines running Linux +* count years since 1970. +*/ + +#ifdef CONFIG_SPARC +#define YEAR0 68 +#else +#define YEAR0 70 +#endif +/* * NOTE: M48T59 only uses BCD mode */ @@ -82,10 +93,7 @@ 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 ;
Quoted 9 lines
drivers/rtc/rtc-m48t59.c static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm) · line 97
Quoted 3 lines
drivers/rtc/rtc-m48t59.c +1
-1-#endif + tm->tm_year +=YEAR0 ;I'm super happy to see someone working on this, while you are it, can you use
m48t59->rtc->start_secsandm48t59->rtc->set_start_timein probe instead of offsettingtm_yearin read_time/set_time so we can later use device tree or any other mechanism to extend the range?
Sure, I will look into it.
Quoted 4 lines
It is super funny because I was telling Geert that I wanted to get rid of this #ifdef
CONFIG_SPARCtwo weeks ago at LPC. That could indeed then come from platform data.
I can't test any patches on SPARC, unless there's some way to do so using QEMU that would satisfy maintainers. (I rely on Daniel to test my patches on an MVME147 system.)
Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit
In reply to Alexandre BelloniQuoted 6 lines · Alexandre Belloni
... while you are it, can you use
m48t59->rtc->start_secsandm48t59->rtc->set_start_timein probe instead of offsettingtm_yearin 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.
arch/sparc/kernel/time_32.c +1 -0
@@ -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 */
arch/sparc/kernel/time_64.c +1 -0
@@ -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 = {
drivers/rtc/rtc-m48t59.c +5 -18
@@ -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);
include/linux/rtc/m48t59.h +3 -0
@@ -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_ */
Alexandre Belloni
maintainerRe: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit
Quoted 69 lines · Finn Thain
Quoted 6 lines · Alexandre Belloni
... while you are it, can you use
m48t59->rtc->start_secsandm48t59->rtc->set_start_timein probe instead of offsettingtm_yearin 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 secondsFri Jan 1 01:01:00 UTC 1971
Tue Nov 24 18:32:44 1998 0.000000 secondsFri Jan 1 01:01:00 UTC 1999
Tue Nov 24 18:32:44 2026 0.000000 secondsSat Jan 1 01:01:00 UTC 2000
Sun Jan 2 23:29:16 2000 0.000000 secondsMon Jan 1 01:01:00 UTC 2024
Tue Jan 2 23:29:16 2024 0.000000 secondsWed Jan 1 01:01:00 UTC 2025
Thu Jan 2 23:29:16 2025 0.000000 secondsSun Jan 1 01:01:00 UTC 2068
hwclock:RTC_SET_TIME: Numerical result out of rangeTue 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 secondsFri Jan 1 01:01:00 UTC 1971
Fri Jan 1 01:01:00 1971 0.000000 secondsFri Jan 1 01:01:00 UTC 1999
Fri Jan 1 01:01:01 1999 0.000000 secondsSat Jan 1 01:01:00 UTC 2000
Sat Jan 1 01:01:00 2000 0.000000 secondsMon Jan 1 01:01:00 UTC 2024
Mon Jan 1 01:01:00 2024 0.000000 secondsWed Jan 1 01:01:00 UTC 2025
Wed Jan 1 01:01:00 2025 0.000000 secondsSun Jan 1 01:01:00 UTC 2068
hwclock:RTC_RD_TIME: Invalid argumentTue Jan 1 01:01:00 UTC 2069
hwclock:RTC_RD_TIME: Invalid argument
Quoted 6 lines
~ #
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.
I'm pretty sure this is avoidable as this is exactly what the offset mechanism is trying to achieve. I guess the issue is in the RTC core because both range_min and start_secs are negative which has never been tested. My plan was to have unit tests for this but this never happened...
Signature · 3 lines
Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
PATCH 2/2 m68k: mvme147, mvme16x: Adopt rtc-m48t59 platform driver
In reply to Finn ThainBoth mvme147 and mvme16x platforms have their own RTC driver implementations that duplicate functionality provided by the rtc-m48t59 driver. Adopt the rtc-m48t59 driver and remove the other ones.
--- arch/m68k/configs/multi_defconfig | 1 + arch/m68k/configs/mvme147_defconfig | 1 + arch/m68k/configs/mvme16x_defconfig | 1 + arch/m68k/include/asm/mvme147hw.h | 19 +--- arch/m68k/include/asm/mvme16xhw.h | 18 +-- arch/m68k/mvme147/config.c | 54 ++++----- arch/m68k/mvme16x/Makefile | 2 +- arch/m68k/mvme16x/config.c | 56 ++++------ arch/m68k/mvme16x/rtc.c | 165 ---------------------------- 9 files changed, 52 insertions(+), 265 deletions(-) delete mode 100644 arch/m68k/mvme16x/rtc.c
arch/m68k/configs/multi_defconfig +1 -0
@@ -506,6 +506,7 @@ CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_MSM6242=m CONFIG_RTC_DRV_RP5C01=m CONFIG_RTC_DRV_GENERIC=m +CONFIG_RTC_DRV_M48T59=m # CONFIG_VIRTIO_MENU is not set # CONFIG_VHOST_MENU is not set # CONFIG_IOMMU_SUPPORT is not set
arch/m68k/configs/mvme147_defconfig +1 -0
@@ -392,6 +392,7 @@ CONFIG_UHID=m CONFIG_RTC_CLASS=y # CONFIG_RTC_NVMEM is not set CONFIG_RTC_DRV_GENERIC=m +CONFIG_RTC_DRV_M48T59=y # CONFIG_VIRTIO_MENU is not set # CONFIG_VHOST_MENU is not set # CONFIG_IOMMU_SUPPORT is not set
arch/m68k/configs/mvme16x_defconfig +1 -0
@@ -393,6 +393,7 @@ CONFIG_UHID=m CONFIG_RTC_CLASS=y # CONFIG_RTC_NVMEM is not set CONFIG_RTC_DRV_GENERIC=m +CONFIG_RTC_DRV_M48T59=y # CONFIG_VIRTIO_MENU is not set # CONFIG_VHOST_MENU is not set # CONFIG_IOMMU_SUPPORT is not set
arch/m68k/include/asm/mvme147hw.h +1 -18
@@ -4,24 +4,7 @@#include <asm/irq.h> -typedef struct { -unsigned char - ctrl, - bcd_sec, - bcd_min, - bcd_hr, - bcd_dow, - bcd_dom, - bcd_mth, - bcd_year; -}MK48T02 ; - -#define RTC_WRITE 0x80 -#define RTC_READ 0x40 -#define RTC_STOP 0x20 - -#define m147_rtc ((MK48T02 * volatile)0xfffe07f8) - +#define MVME147_RTC_BASE 0xfffe0000struct pcc_regs {volatile u_long dma_tadr;
arch/m68k/include/asm/mvme16xhw.h +1 -17
@@ -24,23 +24,7 @@ typedef struct {#define mvmelp ((*(volatile MVMElpPtr)(MVME_LPR_BASE))) -typedef struct { -unsigned char - ctrl, - bcd_sec, - bcd_min, - bcd_hr, - bcd_dow, - bcd_dom, - bcd_mth, - bcd_year; -}MK48T08_t , *MK48T08ptr_t ; - -#define RTC_WRITE 0x80 -#define RTC_READ 0x40 -#define RTC_STOP 0x20 - -#define MVME_RTC_BASE 0xfffc1ff8 +#define MVME_RTC_BASE 0xfffc0000#define MVME_I596_BASE 0xfff46000
arch/m68k/mvme147/config.c +23 -31
85 lines not on this page · raw message
arch/m68k/mvme16x/Makefile +1 -1
@@ -3,4 +3,4 @@ # Makefile for Linux arch/m68k/mvme16x source directory # -obj-y := config.o rtc.o +obj-y := config.o
arch/m68k/mvme16x/config.c +23 -33
89 lines not on this page · raw message
arch/m68k/mvme16x/rtc.c deleted +0 -165
165 lines not on this page · raw message
Signature · 1 line
2.39.5