Hi Arnd, Finn,
On Fri, Jun 22, 2018 at 10:55 AM Arnd Bergmann arnd@arndb.de wrote:
On Fri, Jun 22, 2018 at 7:26 AM, Finn Thain fthain@telegraphics.com.au wrote:
On Tue, 19 Jun 2018, Arnd Bergmann wrote:
The real-time clock on m68k (and powerpc) mac systems uses an unsigned 32-bit value starting in 1904, which overflows in 2040, about two years later than everyone else, but this gets wrapped around in the Linux code in 2038 already because of the deprecated usage of time_t and/or long in the conversion.
Getting rid of the deprecated interfaces makes it work until 2040 as documented, and it could be easily extended by reinterpreting the resulting time64_t as a positive number. For the moment, I'm adding a WARN_ON() that triggers if we encounter a time before 1970 or after 2040 (the two are indistinguishable).
I really don't like the WARN_ON(), but I'd prefer to address that in a separate patch rather than impede the progress of this patch (or of this series, since 3/3 seems to be unrelated).
BTW, have you considered using the same wrap-around test (i.e. YY < 70) that we use for the year register in the other RTC chips?
That wrap-around test would have the same effect as the my original version (aside from the two bugs I now fixed), doing rougly
return time - RTC_OFFSET;
return (u32)(time - RTC_OFFSET);or some other variation of that will give us an RTC that supports all dates between 1970 and 2106. I don't think anyone so far had a strong preference here, so I went with what Mathieu suggested and kept the original Mac behavior, but added the WARN_ON().
So, is this safe to apply? Especially in light of the warnings seen by Meelis with the PPC version.
Thanks!
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