powerpc: use time64_t in read_persistent_clock

[Arnd Bergmann]

On Thu, Jun 14, 2018 at 9:03 PM, Mathieu Malaterre <malat at debian.org> wrote:
> On Thu, Jun 14, 2018 at 1:46 PM Arnd Bergmann <arnd at arndb.de> wrote:
>> On Wed, Jun 13, 2018 at 10:24 PM, Mathieu Malaterre <malat at debian.org> wrote:
>
>> Can you confirm that this patch addresses your problem?
>
> Yes !
>
> Before:
> [    5.986710] rtc-generic rtc-generic: hctosys: unable to read the
> hardware clock
>
> After:
> [    5.579611] rtc-generic rtc-generic: setting system clock to
> 2018-06-14 18:57:00 UTC (1529002620)
>
> So for the above:
>
> Tested-by: Mathieu Malaterre <malat at debian.org>

Thanks a lot!

>> --- a/arch/powerpc/platforms/powermac/time.c
>> +++ b/arch/powerpc/platforms/powermac/time.c
>> @@ -88,7 +88,7 @@ long __init pmac_time_init(void)
>>  static time64_t cuda_get_time(void)
>>  {
>>         struct adb_request req;
>> -       time64_t now;
>> +       u32 now;
>>
>>         if (cuda_request(&req, NULL, 2, CUDA_PACKET, CUDA_GET_TIME) < 0)
>>                 return 0;
>> @@ -132,7 +132,7 @@ static int cuda_set_rtc_time(struct rtc_time *tm)
>>  static time64_t pmu_get_time(void)
>>  {
>>         struct adb_request req;
>> -       time64_t now;
>> +       u32 now;
>>
>>         if (pmu_request(&req, NULL, 1, PMU_READ_RTC) < 0)
>>                 return 0;
>>
>> On the upside, this would possibly extend the life of some machines
>> by another 66 years, on the downside it might cause issues when
>> an empty RTC battery causes the initial system time to be
>> above the 32-bit TIME_T_MAX (instead of going back to 1904).
>
> I would submit the first patch and add the above as comment. I doubt
> anyone would still have a running system by then.

I was about to send a similar patch to the first one for m68k macs, which have
basically the same code. My patch had the same bug, so I'm glad I had
not sent it yet, but I also noticed that I made the opposite decision on m68k
as that code had already been using 'unsigned long' in the conversion (but
then of course would wrap it during the conversion to 'time_t). I've picked
the same approach for both now, using the 1904..2040 range.

       Arnd