Arnd Bergmann <a...@arndb.de> writes: > As Mathieu pointed out, my conversion to time64_t was incorrect and resulted > in negative times to be read from the RTC. The problem is that during the > conversion from a byte array to a time64_t, the 'unsigned char' variable > holding the top byte gets turned into a negative signed 32-bit integer > before being assigned to the 64-bit variable for any times after 1972. > > This changes the logic to cast to an unsigned 32-bit number first for > the Macintosh time and then convert that to the Unix time, which then gives > us a time in the documented 1904..2040 year range. I decided not to use > the longer 1970..2106 range that other drivers use, for consistency with > the literal interpretation of the register, but that could be easily > changed if we decide we want to support any Mac after 2040. > > Just to be on the safe side, I'm also adding a WARN_ON that will trigger > if either the year 2040 has come and is observed by this driver, or we > run into an RTC that got set back to a pre-1970 date for some reason > (the two are indistinguishable). > > For the RTC write functions, Andreas found another problem: both > pmu_request() and cuda_request() are varargs functions, so changing > the type of the arguments passed into them from 32 bit to 64 bit > breaks the API for the set_rtc_time functions. This changes it > back to 32 bits. > > The same code exists in arch/m68k/ and is patched in an identical way now > in a separate patch. > > Fixes: 5bfd643583b2 ("powerpc: use time64_t in read_persistent_clock") > Reported-by: Mathieu Malaterre <ma...@debian.org> > Reported-by: Andreas Schwab <sch...@linux-m68k.org> > Signed-off-by: Arnd Bergmann <a...@arndb.de> > --- > arch/powerpc/platforms/powermac/time.c | 29 ++++++++++++++++++++--------- > 1 file changed, 20 insertions(+), 9 deletions(-)
So I think I can take this patch in isolation via the powerpc tree as a fix for 4.18. I'll leave the other two alone. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html