Hi Arnd, Finn,
On Fri, Jun 22, 2018 at 10:55 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
On Fri, Jun 22, 2018 at 7:26 AM, Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx
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
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
