On Tue, 2018-06-19 at 14:02:27 UTC, Arnd Bergmann wrote: > 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> > Tested-by: Mathieu Malaterre <ma...@debian.org>
Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/22db552b50fa11d8c1d171de908a1f cheers