Commit 22db552b authored by Arnd Bergmann's avatar Arnd Bergmann Committed by Michael Ellerman

powerpc/powermac: Fix rtc read/write functions

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: 5bfd6435 ("powerpc: use time64_t in read_persistent_clock")
Reported-by: default avatarMathieu Malaterre <malat@debian.org>
Reported-by: Andreas Schwab's avatarAndreas Schwab <schwab@linux-m68k.org>
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Tested-by: default avatarMathieu Malaterre <malat@debian.org>
Signed-off-by: Michael Ellerman's avatarMichael Ellerman <mpe@ellerman.id.au>
parent 941c06d5
......@@ -42,7 +42,11 @@
#define DBG(x...)
#endif
/* Apparently the RTC stores seconds since 1 Jan 1904 */
/*
* Offset between Unix time (1970-based) and Mac time (1904-based). Cuda and PMU
* times wrap in 2040. If we need to handle later times, the read_time functions
* need to be changed to interpret wrapped times as post-2040.
*/
#define RTC_OFFSET 2082844800
/*
......@@ -97,8 +101,11 @@ static time64_t cuda_get_time(void)
if (req.reply_len != 7)
printk(KERN_ERR "cuda_get_time: got %d byte reply\n",
req.reply_len);
now = (req.reply[3] << 24) + (req.reply[4] << 16)
+ (req.reply[5] << 8) + req.reply[6];
now = (u32)((req.reply[3] << 24) + (req.reply[4] << 16) +
(req.reply[5] << 8) + req.reply[6]);
/* it's either after year 2040, or the RTC has gone backwards */
WARN_ON(now < RTC_OFFSET);
return now - RTC_OFFSET;
}
......@@ -106,10 +113,10 @@ static time64_t cuda_get_time(void)
static int cuda_set_rtc_time(struct rtc_time *tm)
{
time64_t nowtime;
u32 nowtime;
struct adb_request req;
nowtime = rtc_tm_to_time64(tm) + RTC_OFFSET;
nowtime = lower_32_bits(rtc_tm_to_time64(tm) + RTC_OFFSET);
if (cuda_request(&req, NULL, 6, CUDA_PACKET, CUDA_SET_TIME,
nowtime >> 24, nowtime >> 16, nowtime >> 8,
nowtime) < 0)
......@@ -140,8 +147,12 @@ static time64_t pmu_get_time(void)
if (req.reply_len != 4)
printk(KERN_ERR "pmu_get_time: got %d byte reply from PMU\n",
req.reply_len);
now = (req.reply[0] << 24) + (req.reply[1] << 16)
+ (req.reply[2] << 8) + req.reply[3];
now = (u32)((req.reply[0] << 24) + (req.reply[1] << 16) +
(req.reply[2] << 8) + req.reply[3]);
/* it's either after year 2040, or the RTC has gone backwards */
WARN_ON(now < RTC_OFFSET);
return now - RTC_OFFSET;
}
......@@ -149,10 +160,10 @@ static time64_t pmu_get_time(void)
static int pmu_set_rtc_time(struct rtc_time *tm)
{
time64_t nowtime;
u32 nowtime;
struct adb_request req;
nowtime = rtc_tm_to_time64(tm) + RTC_OFFSET;
nowtime = lower_32_bits(rtc_tm_to_time64(tm) + RTC_OFFSET);
if (pmu_request(&req, NULL, 5, PMU_SET_RTC, nowtime >> 24,
nowtime >> 16, nowtime >> 8, nowtime) < 0)
return -ENXIO;
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment